프롬프트 라이브러리

Feature Flag Rollout taste of a release engineer

• Separate deploy from release: ship code dark behind a flag and turn it on independently of the deployment. Confidence: 0.95
• Use a managed flag service or OpenFeature-compatible SDK instead of home-grown if statements on environment variables. Confidence: 0.80
• Give every flag an owner, a description, a type (release, experiment, ops or permission) and an expected removal date. Confidence: 0.90
• Name flags after the behavior they control, such as checkout-new-payment-form, not after tickets or people. Confidence: 0.85
• Default every flag to the safe, existing behavior when the flag service is unreachable. Confidence: 0.95
• Evaluate flags once per request at the edge of the code path and pass the result down, not deep inside loops. Confidence: 0.80
• Roll out gradually: internal users first, then 1%, 10%, 50% and 100%, watching metrics at each step. Confidence: 0.90
• Use sticky, hash-based bucketing on a stable user or account ID so people do not flip between variants. Confidence: 0.90
• Define the success and guardrail metrics before the rollout starts, not after looking at the dashboard. Confidence: 0.85
• Wire automatic rollback to error rate and latency alerts for risky changes. Confidence: 0.75
• Keep a kill switch for every expensive or external dependency so operations can turn it off without a deploy. Confidence:

LLM Application taste of an AI product engineer

• Treat prompts as code: keep them in version-controlled files with names, versions and owners, not inline strings scattered around. Confidence: 0.90
• Build an evaluation set from real user inputs before tuning prompts, and rerun it on every prompt or model change. Confidence: 0.95
• Ask for structured output with a JSON schema or tool calls and validate it with a schema library before using it. Confidence: 0.95
• Put a thin gateway or wrapper around model providers so switching models or adding fallbacks is a config change. Confidence: 0.85
• Pin exact model versions in production and upgrade them deliberately after the evals pass. Confidence: 0.90
• Stream responses to the user whenever the output is longer than a sentence or two. Confidence: 0.85
• Start retrieval with simple hybrid search (keywords plus embeddings) and add reranking before reaching for complex RAG pipelines. Confidence: 0.80
• Chunk documents along their natural structure (headings, sections) and keep source metadata so answers can cite them. Confidence: 0.85
• Keep the context small and relevant; more retrieved text often makes answers worse, not better. Confidence: 0.80
• Give agents a short list of narrow, well-described tools with strict input schemas instead of one do-everything tool. Confidence: 0.85
• Put hard limits on agent loops: maximum steps, ma

Jetpack Compose Android App taste of an Android engineer

• Build new screens entirely in Jetpack Compose and keep Views only behind interop for legacy parts. Confidence: 0.90
• Write the whole app in Kotlin with coroutines and Flow; no new RxJava or Java code. Confidence: 0.90
• Follow unidirectional data flow: the ViewModel exposes one immutable UiState as StateFlow and receives events. Confidence: 0.90
• Collect flows in composables with collectAsStateWithLifecycle, not plain collectAsState. Confidence: 0.85
• Hoist state out of composables so most UI functions are stateless and previewable. Confidence: 0.90
• Pass a Modifier parameter as the first optional argument of every reusable composable. Confidence: 0.85
• Keep side effects in LaunchedEffect, DisposableEffect or the ViewModel, never directly in the composable body. Confidence: 0.90
• Mark UI models immutable and use stable collections so recomposition stays cheap. Confidence: 0.75
• Use Hilt for dependency injection and avoid service locators or global singletons. Confidence: 0.80
• Use the repository pattern with Room for local data and Retrofit or Ktor for the network, offline first where it matters. Confidence: 0.80
• Use type-safe Navigation Compose routes instead of string-built destinations. Confidence: 0.80
• Modularize by feature with a shared core module once the app grows past a handful of screens. Confide

Data Pipeline taste of a data engineer

• Prefer ELT: land raw data unchanged first, then transform inside the warehouse. Confidence: 0.85
• Keep raw, staging and mart layers separate, and never let dashboards read from raw tables. Confidence: 0.90
• Model transformations in dbt (or SQLMesh) as version-controlled SQL with code review like any other code. Confidence: 0.90
• Make every job idempotent: rerunning a day must produce the same result without duplicates. Confidence: 0.95
• Partition large tables by event date and process data in date-bounded increments. Confidence: 0.85
• Backfills are a first-class operation with a documented command, not a manual one-off script. Confidence: 0.85
• Add tests for uniqueness, not-null, accepted values and referential integrity on every important model. Confidence: 0.90
• Define data contracts with upstream producers so schema changes fail in their CI, not in your pipeline. Confidence: 0.80
• Track freshness per source and alert when data is late, not only when a job fails. Confidence: 0.90
• Orchestrate with Airflow, Dagster or Prefect, and keep heavy computation out of the orchestrator workers. Confidence: 0.80
• Prefer asset-based orchestration that knows which tables depend on which over plain task graphs. Confidence: 0.70
• Store timestamps in UTC and convert to local time only in the presentation layer. Confidence: 0.95
• Use Parq

Django Web App taste of a Python backend engineer

• Start every project with a custom user model (AbstractUser) even if it adds no fields yet. Confidence: 0.95
• Split settings by environment and read secrets and URLs from environment variables with django-environ or similar. Confidence: 0.90
• Keep apps small and domain-focused; an app that imports half the project is a sign it should be split or merged. Confidence: 0.75
• Put business logic in plain service functions or model methods, not in views, serializers or signals. Confidence: 0.85
• Avoid signals for core workflows; call the side effect explicitly so the flow is readable and testable. Confidence: 0.85
• Use select_related and prefetch_related deliberately and check query counts with django-debug-toolbar or assertNumQueries. Confidence: 0.90
• Add database constraints (UniqueConstraint, CheckConstraint) instead of relying only on form or serializer validation. Confidence: 0.90
• Review every generated migration before committing and never edit a migration that has already run in production. Confidence: 0.90
• Write data migrations with RunPython using apps.get_model, never importing models directly. Confidence: 0.85
• Prefer class-based generic views for CRUD and function views for anything with unusual control flow. Confidence: 0.70
• Use Django REST Framework or django-ninja for APIs, with explicit serializers or s

SwiftUI iOS App taste of a senior iOS developer

• Build new screens in SwiftUI and drop to UIKit only through UIViewRepresentable for gaps. Confidence: 0.85
• Use the Observation framework (@Observable) for view models on iOS 17+, not ObservableObject with @Published. Confidence: 0.85
• Keep views small and composable; extract a subview once a body passes about 50 lines. Confidence: 0.80
• Own state with @State at the lowest view that needs it and pass bindings down instead of global singletons. Confidence: 0.85
• Use Swift Concurrency (async/await, actors, structured tasks) everywhere; no new completion-handler or Combine-based APIs. Confidence: 0.85
• Start async work with the .task modifier so it is cancelled automatically when the view disappears. Confidence: 0.90
• Turn on strict concurrency checking (Swift 6 language mode) and fix Sendable warnings early. Confidence: 0.80
• Drive navigation with NavigationStack and a typed path, routed through a small coordinator or router object. Confidence: 0.80
• Inject dependencies through initializers or the Environment so previews and tests can swap in fakes. Confidence: 0.85
• Split features into local Swift packages managed by Swift Package Manager; avoid CocoaPods for new projects. Confidence: 0.85
• Give every view a #Preview with realistic sample data, including empty, loading and error states. Confidence: 0.85
• Model loadin

Event-Driven Architecture taste of a distributed systems engineer

• Use events to announce facts that already happened (OrderPlaced), and commands only for requests to a single owner (ChargeCard). Confidence: 0.90
• Name events in the past tense using domain language, never after the producing table or service. Confidence: 0.85
• Define every event with a versioned schema (Avro, Protobuf or JSON Schema) in a registry and check compatibility in CI. Confidence: 0.90
• Evolve schemas only with backward-compatible changes; publish a new event type for breaking changes. Confidence: 0.85
• Assume at-least-once delivery and make every consumer idempotent with a deduplication key. Confidence: 0.95
• Publish events through the transactional outbox pattern so database writes and messages never diverge. Confidence: 0.90
• Include event id, type, version, timestamp, correlation id and causation id in every envelope. Confidence: 0.85
• Keep event payloads self-contained enough for common consumers, but do not dump whole aggregates. Confidence: 0.75
• Partition by aggregate id when ordering matters, and never rely on global ordering. Confidence: 0.85
• Route poison messages to a dead-letter queue after bounded retries with exponential backoff and jitter. Confidence: 0.90
• Alert on consumer lag and dead-letter queue depth, not just on broker health. Confidence: 0.90
• Propagate trace conte

Code Review taste of a staff engineer

• Keep pull requests small enough to review in one sitting, ideally under 400 changed lines; split refactors from behavior changes. Confidence: 0.90
• Write a PR description that states the why, the approach, how it was tested and what is out of scope. Confidence: 0.90
• Self-review the diff before requesting review and leave comments on the non-obvious parts. Confidence: 0.85
• Let formatters, linters and type checkers settle style in CI; humans never comment on whitespace or import order. Confidence: 0.95
• Review for correctness, design and maintainability first, naming and readability second. Confidence: 0.85
• Prefix comments with their weight (nit:, suggestion:, question:, blocking:) so the author knows what must change. Confidence: 0.85
• Ask questions instead of issuing orders ("What happens if this list is empty?"). Confidence: 0.80
• Approve with minor nits rather than blocking; trust the author to address them before merge. Confidence: 0.80
• Respond to review requests within one working day; a stale PR costs more than an interrupted hour. Confidence: 0.85
• Require tests for every bug fix that would have failed before the fix. Confidence: 0.90
• Check error paths, timeouts, retries and logging, not just the happy path. Confidence: 0.85
• Flag any new dependency and ask whether it is maintained, licensed correctly and worth its

==========================================================

Universal LLM Operating Guidelines & Karpathy Rules

==========================================================

VERSION: 1.2.0

AUTHOR: Scott Malin, CISSP

LAST UPDATED: 2026-10-22

#

ATTRIBUTION:

Adapted from principles associated with Andrej Karpathy's

observations on LLM-assisted coding and informed by the

open-source multica-ai/andrej-karpathy-skills repository.

#

This document is an independent practical adaptation.

It does not claim that all rules or wording originated

with Andrej Karpathy.

#

PURPOSE:

Establish practical operating rules for LLM-assisted

software development. Reduce hallucinations, unnecessary

complexity, uncontrolled modifications, architectural

drift, and unsupported claims of completion.

#

DESIGN PRINCIPLE:

Make the smallest correct change, preserve what works,

verify what can be verified, and report what actually

happened.

#

CHANGELOG:

- v1.2.0 (2026-10-22):

- Added Executive Summary / Quick Reference section for high-density

prompt adherence and rapid context parsing.

#

- v1.1.0 (2026-10-22):

- Clarified when to ask questions versus proceed with explicit assumptions.

- Defined simplicity in terms of unnecessary complexity, not merely

minimum code length.

- Strengthened root-cause analysis and surgical changes.

- Ad

Web Accessibility taste of a frontend engineer

• Use semantic HTML first (button, a, nav, main, label); add ARIA only when no native element fits. Confidence: 0.95
• Never put click handlers on div or span; if it acts like a button, it is a button. Confidence: 0.95
• Links navigate and buttons perform actions; do not swap them for styling reasons. Confidence: 0.90
• Every form input has a visible, programmatically associated label; placeholders are not labels. Confidence: 0.95
• Keep one h1 per page and never skip heading levels for visual size; style with CSS instead. Confidence: 0.80
• Write alt text that describes the purpose of the image, and use alt="" for purely decorative images. Confidence: 0.90
• Keep a visible focus indicator on every interactive element; use :focus-visible rather than removing outlines. Confidence: 0.95
• Every feature must work with the keyboard alone, in a logical tab order, with no keyboard traps. Confidence: 0.95
• Avoid positive tabindex values; fix the DOM order instead. Confidence: 0.90
• Meet WCAG AA contrast: 4.5:1 for body text and 3:1 for large text and UI components. Confidence: 0.90
• Never convey meaning by color alone; pair it with text, an icon or a pattern. Confidence: 0.90
• Use the native dialog element (or a well-tested library) for modals, trap focus while open and return focus to the trigger on close. Confidence: 0.85
• Announ

GraphQL API taste of a platform engineer

• Design the schema around client use cases and domain language, not around database tables. Confidence: 0.90
• Generate types for both server and client from the schema (GraphQL Code Generator or equivalent); never hand-write response types. Confidence: 0.90
• Make fields non-null by default only when the server can always resolve them; keep fields that depend on other services nullable so one failure does not null out the whole response. Confidence: 0.80
• Use one input object per mutation (createOrder(input: CreateOrderInput!)) and return a payload type, not the bare entity. Confidence: 0.85
• Return expected business errors as typed union members in the payload (e.g. OrderCreated | InsufficientStock); reserve the top-level errors array for unexpected failures. Confidence: 0.75
• Paginate lists with Relay-style cursor connections (edges, node, pageInfo) and cap first/last at a sane maximum. Confidence: 0.80
• Batch and cache data loading per request with DataLoader to kill N+1 queries. Confidence: 0.95
• Enforce query depth and complexity limits at the gateway. Confidence: 0.90
• Use persisted queries (allowlisted operation hashes) for first-party clients in production. Confidence: 0.80
• Disable introspection on public production endpoints unless the API is meant to be public. Confidence: 0.70
• Evolve the schema additively and mar

Shell scripting taste of a DevOps engineer

• Start every script with #!/usr/bin/env bash and set -euo pipefail. Confidence: 0.90
• Switch to Python or Go once a script passes about 100 lines or needs real data structures. Confidence: 0.85
• Run ShellCheck in CI and fix warnings instead of silencing them. Confidence: 0.95
• Format scripts with shfmt so diffs stay small. Confidence: 0.75
• Quote every variable expansion ("$var") unless word splitting is intended and commented. Confidence: 0.95
• Use [[ ]] for tests and $(...) for command substitution, never backticks. Confidence: 0.90
• Declare variables inside functions with local. Confidence: 0.85
• Put the logic in functions and call a main "$@" at the bottom of the file. Confidence: 0.80
• Clean up temporary files with mktemp and trap '...' EXIT. Confidence: 0.90
• Write errors and logs to stderr and keep stdout for data other tools can pipe. Confidence: 0.85
• Exit with a non-zero status and a clear message when something fails. Confidence: 0.90
• Provide a usage function and handle -h and --help. Confidence: 0.80
• Parse options with getopts or a simple case loop, not ad hoc positional checks. Confidence: 0.75
• Check required commands up front with command -v and fail early when one is missing. Confidence: 0.85
• Read configuration from environment variables with defaults, such as ${PORT:-8080}. Confidence: 0.80
• Never

Web performance taste of a frontend engineer

• Measure Core Web Vitals (LCP, INP, CLS) from real users, not only from lab Lighthouse runs. Confidence: 0.90
• Set a performance budget for JavaScript size and LCP, and fail CI when a change breaks it. Confidence: 0.80
• Render the first view on the server or statically; do not ship a blank page that waits for JavaScript. Confidence: 0.90
• Ship less JavaScript before optimizing the JavaScript you ship. Confidence: 0.90
• Split code by route and lazy-load heavy widgets such as editors, charts, and maps. Confidence: 0.85
• Check the bundle analyzer before adding a dependency, and prefer small, tree-shakable libraries. Confidence: 0.80
• Serve images in AVIF or WebP with responsive srcset and explicit width and height. Confidence: 0.90
• Mark the LCP image with fetchpriority="high" and never lazy-load it. Confidence: 0.85
• Lazy-load below-the-fold images and iframes with loading="lazy". Confidence: 0.85
• Self-host fonts, subset them, preload the main one, and use font-display: swap. Confidence: 0.80
• Reserve space for ads, embeds, and late content so the layout does not shift. Confidence: 0.85
• Break up long tasks over 50 ms and yield to the main thread to keep INP low. Confidence: 0.80
• Load third-party scripts with defer or after interaction, and audit each one for real value. Confidence: 0.85
• Cache hashed static assets wi

PostgreSQL taste of a backend engineer

• Use bigint identity columns (GENERATED ALWAYS AS IDENTITY) for primary keys; reach for UUIDv7 only when ids must be generated outside the database. Confidence: 0.80
• Store timestamps as timestamptz in UTC, never timestamp without time zone. Confidence: 0.95
• Use text with a CHECK constraint instead of varchar(n) for length limits. Confidence: 0.80
• Store money as numeric or as integer minor units, never as float. Confidence: 0.95
• Name tables in plural snake_case and foreign keys as <singular>_id. Confidence: 0.70
• Declare NOT NULL by default and allow NULL only when "unknown" is a real state. Confidence: 0.85
• Enforce invariants in the database with foreign keys, UNIQUE, and CHECK constraints, not only in application code. Confidence: 0.90
• Index every foreign key column that is used in joins or cascading deletes. Confidence: 0.85
• Read EXPLAIN (ANALYZE, BUFFERS) before adding an index, and again after to prove it helped. Confidence: 0.90
• Prefer partial and expression indexes over wide composite indexes for skewed filters. Confidence: 0.70
• Create indexes on large tables with CREATE INDEX CONCURRENTLY. Confidence: 0.90
• Use jsonb for genuinely schemaless attributes, but promote fields you filter on into real columns. Confidence: 0.80
• Paginate with keyset (WHERE id > $last ORDER BY id LIMIT n) instead of large OFFSET valu

Web security taste of a full-stack developer

• Use the framework's auth or a vetted library; never hand-roll password storage or session handling. Confidence: 0.95
• Hash passwords with Argon2id or bcrypt and a sensible work factor. Confidence: 0.95
• Store sessions in HttpOnly, Secure, SameSite=Lax cookies rather than localStorage. Confidence: 0.90
• Rotate the session id on login and on privilege change. Confidence: 0.85
• Offer passkeys or TOTP as a second factor, and require it for admin accounts. Confidence: 0.85
• Check authorization on the server for every request, including on object ids, to stop IDOR bugs. Confidence: 0.95
• Deny by default: new routes are private until someone explicitly makes them public. Confidence: 0.85
• Use parameterized queries or an ORM everywhere; never build SQL with string concatenation. Confidence: 0.95
• Rely on the template engine's automatic escaping and treat every raw HTML escape hatch as a review flag. Confidence: 0.90
• Ship a strict Content Security Policy with nonces, starting in report-only mode. Confidence: 0.80
• Send HSTS, X-Content-Type-Options: nosniff, and frame-ancestors on every response. Confidence: 0.85
• Protect state-changing requests with SameSite cookies plus CSRF tokens or an origin check. Confidence: 0.85
• Rate-limit login, signup, password reset, and other expensive endpoints. Confidence: 0.90
• Return the same

Kubernetes taste of a platform team

• Deploy everything through GitOps (Argo CD or Flux); nobody runs kubectl apply against production by hand. Confidence: 0.90
• Package shared services with Helm or Kustomize, but keep per-environment overlays small and readable. Confidence: 0.80
• Set CPU and memory requests on every container, and set a memory limit equal to the request. Confidence: 0.90
• Avoid CPU limits on latency-sensitive services; rely on requests and node sizing to prevent throttling. Confidence: 0.70
• Give every Deployment a readiness probe; add a liveness probe only when the app can truly deadlock. Confidence: 0.85
• Use a startup probe for slow-booting apps instead of a long initialDelaySeconds on liveness. Confidence: 0.80
• Run at least two replicas behind a PodDisruptionBudget for anything users depend on. Confidence: 0.90
• Spread replicas across zones with topologySpreadConstraints. Confidence: 0.80
• Pin images by digest or an immutable version tag, never latest. Confidence: 0.95
• Run containers as non-root with a read-only root filesystem and all capabilities dropped. Confidence: 0.90
• Enforce the restricted Pod Security Standard on application namespaces. Confidence: 0.80
• Start every namespace with a default-deny NetworkPolicy and open only the flows you need. Confidence: 0.80
• Give each workload its own ServiceAccount and disable token automount wh

name: learning-linux-for-beginer
description: A clear description of what this skill does and when to use it
---

learning linux for beginer

Describe what this skill does and how the agent should use it. using the repo https://github.com/TunB3ru/LINUX-WORLD.git

Instructions

• Step 1: ...
• Step 2: ...

CSS taste of a design-minded frontend developer

• Use Tailwind CSS utility classes for component styling in application code. Confidence: 0.80
• Define colors, spacing, radii and fonts as design tokens in CSS custom properties. Confidence: 0.90
• Never hardcode hex colors inside components; always reference a token. Confidence: 0.85
• Build layouts with flexbox and grid, with gap for spacing instead of margins between siblings. Confidence: 0.90
• Design mobile first and add min-width breakpoints for larger screens. Confidence: 0.85
• Use container queries for components that live in containers of different widths. Confidence: 0.75
• Use rem for font sizes and spacing, and px only for hairline borders. Confidence: 0.80
• Use clamp() for fluid typography instead of many breakpoint overrides. Confidence: 0.75
• Keep specificity flat: single class selectors, no IDs, and no !important outside utilities. Confidence: 0.90
• Use cascade layers to order reset, base, components and utilities. Confidence: 0.70
• Support dark mode with prefers-color-scheme plus tokens, not duplicated component styles. Confidence: 0.85
• Respect prefers-reduced-motion and disable non-essential animation when it is set. Confidence: 0.90
• Never remove focus outlines; style them with :focus-visible instead. Confidence: 0.95
• Meet WCAG AA contrast for all text and interactive elements. Confidence: 0.90
• An

Terraform taste of a cloud platform engineer

• Pin the Terraform version and every provider version, and commit .terraform.lock.hcl. Confidence: 0.95
• Store state remotely with locking enabled, for example S3 with DynamoDB or Terraform Cloud. Confidence: 0.95
• Split state per environment and per system so one apply never touches everything. Confidence: 0.90
• Use separate directories per environment instead of Terraform workspaces for prod and staging. Confidence: 0.75
• Keep modules small and focused on one concern, such as a network or a database. Confidence: 0.85
• Pin module sources to a tag or version, never to a moving branch. Confidence: 0.90
• Give every variable a type and a description, and add validation blocks for risky inputs. Confidence: 0.85
• Expose only the outputs that other stacks actually consume. Confidence: 0.70
• Name resources in snake_case and avoid repeating the resource type in the name. Confidence: 0.75
• Apply a shared tag set (owner, environment, cost center) through provider default_tags. Confidence: 0.85
• Prefer for_each over count so adding or removing an item does not reshuffle addresses. Confidence: 0.90
• Use moved blocks for refactors instead of manual terraform state mv. Confidence: 0.85
• Bring existing resources in with import blocks that are reviewed in a pull request. Confidence: 0.80
• Run terraform fmt, validate and tflint in CI

Git workflow taste of a trunk-based team

• Work trunk-based: short-lived branches off main, merged within two days. Confidence: 0.90
• Name branches as <type>/<short-topic>, for example fix/login-redirect. Confidence: 0.75
• Write commit subjects in the imperative mood and keep them under 72 characters. Confidence: 0.90
• Use Conventional Commits prefixes (feat, fix, chore, docs, refactor) so changelogs can be generated. Confidence: 0.80
• Explain why a change was made in the commit body, not what the diff already shows. Confidence: 0.85
• Keep each commit buildable and focused on one logical change. Confidence: 0.85
• Rebase your branch onto main instead of merging main into it. Confidence: 0.80
• Squash-merge pull requests so main has one commit per change. Confidence: 0.75
• Keep pull requests under about 400 changed lines; split larger work into stacked PRs. Confidence: 0.85
• Put a short what, why and how-to-test section in every pull request description. Confidence: 0.85
• Require one approving review and green CI before merging to main. Confidence: 0.90
• Protect main: no direct pushes and no force pushes. Confidence: 0.95
• Only force push your own branch, and always with --force-with-lease. Confidence: 0.90
• Hide unfinished features behind flags instead of keeping long-lived feature branches. Confidence: 0.85
• Tag releases with semantic version tags such as v1.4.2

Monorepo taste of a platform engineer

• Use pnpm workspaces with a single lockfile at the repository root. Confidence: 0.95
• Put deployable apps in apps/ and shared libraries in packages/. Confidence: 0.90
• Orchestrate tasks with Turborepo and enable remote caching in CI. Confidence: 0.85
• Reference internal packages with the workspace:* protocol. Confidence: 0.90
• Scope every internal package name under one npm scope such as @acme/. Confidence: 0.85
• Share a base tsconfig from a packages/tsconfig package and extend it everywhere. Confidence: 0.85
• Use TypeScript project references so the editor and tsc build incrementally. Confidence: 0.70
• Keep one version of each external dependency across the repo, enforced with syncpack. Confidence: 0.80
• Ship internal packages as TypeScript source and let apps compile them, unless they are published. Confidence: 0.75
• Version and publish public packages with Changesets. Confidence: 0.85
• Run CI only for packages affected by the change, using turbo --filter with a git range. Confidence: 0.85
• Forbid deep imports between packages and allow only the declared exports map. Confidence: 0.85
• Enforce dependency boundaries with a lint rule so apps never import other apps. Confidence: 0.90
• Keep the root package.json free of runtime dependencies. Confidence: 0.80
• Assign owners per directory with a CODEOWNERS file. Confidence: 0.80

Go service taste of a backend engineer

• Use the standard library net/http router from Go 1.22 before reaching for a framework. Confidence: 0.85
• Lay the project out as cmd/<service>/main.go plus internal/ packages, and skip pkg/. Confidence: 0.80
• Keep main.go thin: read config, wire dependencies and start the server. Confidence: 0.90
• Pass context.Context as the first argument to every function that does I/O. Confidence: 0.95
• Wrap errors with fmt.Errorf and %w, and check them with errors.Is and errors.As. Confidence: 0.95
• Log with log/slog in JSON format and include a request ID on every line. Confidence: 0.90
• Read configuration from environment variables into one typed struct at startup. Confidence: 0.85
• Fail fast at startup when required configuration is missing. Confidence: 0.90
• Write SQL by hand and generate typed code with sqlc instead of using an ORM. Confidence: 0.80
• Use pgx as the Postgres driver with a connection pool. Confidence: 0.85
• Define small interfaces in the package that consumes them, not the one that implements them. Confidence: 0.85
• Use table-driven tests with t.Run subtests. Confidence: 0.90
• Run go test with -race in CI on every pull request. Confidence: 0.90
• Lint with golangci-lint using a short, curated list of linters. Confidence: 0.80
• Shut down gracefully on SIGTERM with signal.NotifyContext and server.Shutdown. Confidence:

Testing taste of a pragmatic TypeScript team

• Use vitest as the default test runner for unit and integration tests. Confidence: 0.90
• Keep test files next to the code they cover as *.test.ts. Confidence: 0.85
• Name tests as plain sentences that describe behavior, not method names. Confidence: 0.90
• Follow arrange, act, assert with a blank line between each phase. Confidence: 0.75
• Test public behavior through the module API instead of private functions. Confidence: 0.90
• Prefer real collaborators and in-memory fakes over mocks. Confidence: 0.85
• Mock only at process boundaries such as the network, the clock and randomness. Confidence: 0.90
• Intercept HTTP with msw instead of stubbing fetch by hand. Confidence: 0.80
• Run database tests against a real Postgres in Testcontainers, not SQLite. Confidence: 0.80
• Freeze time with fake timers and pass seeds to anything random. Confidence: 0.90
• Build test data with small factory functions that accept overrides. Confidence: 0.85
• Keep snapshot tests rare and small, and review every snapshot diff. Confidence: 0.75
• Use Playwright for a thin layer of end-to-end tests on critical user flows only. Confidence: 0.85
• Select elements by role and accessible name in UI tests, never by CSS class. Confidence: 0.90
• Treat a flaky test as a bug: quarantine it the same day and fix or delete it within a week. Confidence: 0.85
• Never

role: Performance engineer who designs safe, realistic load tests
task: >
Turn a short description of a web service, API, or background worker into a complete
load test plan in YAML that a team can review, run, and repeat. The plan must protect
production, model real traffic, and define clear pass/fail criteria before any test runs.

ask_first:

• What is being tested (service name, endpoints or jobs, dependencies such as databases, caches, queues, third-party APIs)
• Current traffic shape (average and peak requests per second, daily pattern, read/write mix, payload sizes)
• Business goal for the test (launch readiness, capacity for an event, regression check, cost tuning)
• Existing SLOs or latency targets, if any
• Target environment (staging, production-like, production with guard rails) and who owns it
• Preferred tool (k6, Locust, Gatling, JMeter, Artillery, or "recommend one")

rules:

• Never plan an unannounced test against production or a third-party API. Mock or stub external services unless the provider explicitly allows load.
• Always include abort conditions and a named person who can stop the test.
• Use realistic think time, data variety, and auth flows; avoid hammering a single cached URL.
• Ramp gradually; never start at peak load.
• If inputs are missing, fill reasonable defaults and list them under assumptions.
• Output only valid