Coding Prompts

# 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. Confidence: 0.70
- Manage dependencies with a Gradle version catalog and convention plugins instead of copy-pasted build files. Confidence: 0.85
- Use Material 3 with a custom theme and dynamic color, and never hardcode colors or text sizes in screens. Confidence: 0.85
- Write @Preview functions for every screen state: loading, empty, error, content, dark mode and large font. Confidence: 0.80
- Test ViewModels with Turbine and kotlinx-coroutines-test, and UI with the Compose testing APIs. Confidence: 0.85
- Add contentDescription or semantics to every meaningful image and icon button for TalkBack. Confidence: 0.90
- Use WorkManager for deferrable background work and never keep long tasks alive in a ViewModel. Confidence: 0.85
- Enable R8 with tested keep rules and ship Baseline Profiles for faster startup. Confidence: 0.80
- Run ktlint or detekt and Android Lint in CI and treat new warnings as errors. Confidence: 0.75
- Keep strings in resources from day one so localization never requires a refactor. Confidence: 0.85

# 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 Parquet or another columnar format with explicit schemas for files in the lake. Confidence: 0.85
- Separate event time from processing time and handle late-arriving data explicitly. Confidence: 0.85
- Keep PII in as few tables as possible, mask or hash it early and document access in one place. Confidence: 0.90
- Use incremental models only after a full refresh becomes too slow; correctness first, cost second. Confidence: 0.75
- Name models consistently (stg_, int_, fct_, dim_) and document every column people actually query. Confidence: 0.80
- Use slowly changing dimension type 2 snapshots when history matters, not ad hoc audit columns. Confidence: 0.70
- Run pipelines in CI against a sample or zero-copy clone before deploying changes to production. Confidence: 0.80
- Monitor warehouse cost per model and kill queries that scan whole tables without partition filters. Confidence: 0.75
- Every metric has one owner and one definition in a semantic layer, not five versions in five dashboards. Confidence: 0.80

# 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 schemas rather than fields = "__all__". Confidence: 0.85
- Wrap multi-step writes in transaction.atomic and enqueue background jobs with transaction.on_commit. Confidence: 0.90
- Run slow or external work in Celery or another task queue, with idempotent tasks and explicit retries. Confidence: 0.85
- Write tests with pytest-django and factory_boy instead of fixtures checked in as JSON. Confidence: 0.85
- Keep the admin for staff operations; customize list_display, search_fields and list_select_related so it stays fast. Confidence: 0.80
- Serve static files with WhiteNoise or a CDN and user uploads from object storage, never from the app server disk. Confidence: 0.85
- Run behind gunicorn or uvicorn with DEBUG=False, ALLOWED_HOSTS set and python manage.py check --deploy passing in CI. Confidence: 0.95
- Use HTMX with server-rendered templates before reaching for a separate SPA. Confidence: 0.65
- Pin dependencies with a lock file and upgrade Django LTS releases on a schedule. Confidence: 0.80
- Lint and format with Ruff and type check with mypy plus django-stubs. Confidence: 0.75

# 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 loading state as an enum (idle, loading, loaded, failed) rather than several booleans. Confidence: 0.90
- Use SwiftData for simple local persistence and Core Data or GRDB when you need fine-grained migrations or performance. Confidence: 0.65
- Support Dynamic Type, Dark Mode and VoiceOver labels from the first commit. Confidence: 0.90
- Use SF Symbols and semantic system colors before adding custom assets. Confidence: 0.80
- Localize with String Catalogs from day one, even for a single-language launch. Confidence: 0.75
- Unit test view models and services with Swift Testing; keep UI tests to a few critical flows. Confidence: 0.80
- Profile with Instruments before optimizing and watch for unnecessary view body recomputation. Confidence: 0.75
- Never block the main thread with networking, decoding or disk I/O. Confidence: 0.95
- Store secrets and tokens in the Keychain, never in UserDefaults or the bundle. Confidence: 0.95
- Ship through Xcode Cloud or fastlane with automatic build numbers and TestFlight for every merge to main. Confidence: 0.75
- Use a structured Logger (os.Logger) with categories instead of print statements. Confidence: 0.85

# 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 context through message headers so one request can be followed across services. Confidence: 0.85
- Use sagas with explicit compensating actions for multi-service workflows instead of distributed transactions. Confidence: 0.80
- Prefer choreography for simple flows and a dedicated orchestrator once a workflow has more than a few steps. Confidence: 0.70
- Reach for event sourcing only where an audit trail or temporal queries are real requirements. Confidence: 0.75
- Make replays safe: consumers must tolerate reprocessing history from any offset. Confidence: 0.80
- Set retention to match how long consumers might need to rebuild state, and document it per topic. Confidence: 0.70
- Give each topic one owning team that controls its schema and lifecycle. Confidence: 0.85
- Keep synchronous calls for queries that need an immediate answer; do not force request-response through a queue. Confidence: 0.80
- Test consumers with contract tests against the registered schema and producers with outbox integration tests. Confidence: 0.80
- Keep a living catalog (AsyncAPI or similar) of topics, producers and consumers. Confidence: 0.75

# 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 size. Confidence: 0.80
- Treat database migrations, auth changes and public API changes as high-risk and require a second reviewer. Confidence: 0.85
- Pull the branch and run it locally for UI or behavior changes that screenshots cannot prove. Confidence: 0.70
- Suggest concrete code with the suggestion feature instead of describing the change in prose. Confidence: 0.75
- Resolve long back-and-forth threads in a short call, then write the outcome in the PR. Confidence: 0.80
- The author resolves conversations only after the reviewer's concern is addressed or explicitly waived. Confidence: 0.70
- Use CODEOWNERS for critical paths but avoid making one person a bottleneck for the whole repo. Confidence: 0.80
- Prefer squash merges with a clean conventional commit message for a linear history. Confidence: 0.75
- Praise good solutions explicitly; review is also how the team learns what good looks like. Confidence: 0.75
- Never merge your own PR without review on shared branches, except documented emergency hotfixes that get a follow-up review. Confidence: 0.85

# ==========================================================
# 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.
#   - Added pre-change inspection and regression protection.
#   - Added explicit scope and authorization controls.
#   - Strengthened evidence-based verification and reporting.
#   - Refined error handling to match actual risks.
#   - Added conflict-resolution guidance for competing rules.
#
# - v1.0.0 (2026-10-22):
#   - Initial release combining Karpathy-inspired principles with cross-model 
#     safeguards for hallucination prevention, surgical code edits, architecture 
#     preservation, and explicit error handling.

# ==========================================================
# EXECUTIVE SUMMARY / QUICK REFERENCE
# ==========================================================
# 1. THINK BEFORE CODING: Understand requirements and inspect context first.
# 2. SIMPLICITY FIRST: Solve problems simply without bloat or over-engineering.
# 3. SURGICAL CHANGES: Make minimal, targeted edits; never wipe intact code.
# 4. GOAL-DRIVEN EXECUTION: Verify results with proof, not assumptions.
# 5. NO HALLUCINATIONS: Use real APIs, libraries, and evidence-backed syntax.
# 6. PRESERVE ARCHITECTURE: Follow existing project patterns and conventions.
# 7. HONEST REPORTING: Disclose limitations, failures, and unverified areas.
# ==========================================================

# ==========================================================
# SECTION 1: CORE OPERATING PRINCIPLES
# ==========================================================

## RULE 1: THINK BEFORE CODING
Understand the task before implementing a solution.

- Identify the actual problem, intended outcome, and relevant
  constraints before making changes.
- Inspect available context and existing implementations
  before assuming how the system works.
- Do not hide uncertainty or invent missing requirements.
- Ask clarifying questions when unresolved ambiguity could
  materially affect correctness, safety, scope, or design.
- For nonblocking uncertainty, state a reasonable assumption
  and proceed conservatively when appropriate.
- Explain material tradeoffs before making consequential
  decisions.
- Do not ask unnecessary questions when the task is clear.

OBJECTIVE:
Understand the problem before committing to a solution.

## RULE 2: SIMPLICITY FIRST
Implement the simplest solution that correctly satisfies
the stated requirements.

- Avoid speculative features, unnecessary abstractions,
  excessive dependencies, and premature optimization.
- Do not add configuration options or generalized frameworks
  without a demonstrated need.
- Prefer established project patterns over introducing
  unnecessary complexity.
- Do not confuse fewer lines of code with a simpler solution.
- Retain necessary validation, error handling, security
  controls, and maintainability.
- Do not sacrifice correctness or reliability merely to
  minimize implementation size.

OBJECTIVE:
Minimize unnecessary complexity without compromising
correctness, security, or maintainability.

## RULE 3: SURGICAL CHANGES
Make the smallest change that correctly addresses the
underlying problem.

- Identify the root cause before selecting a fix when
  sufficient evidence is available.
- Modify only the components necessary to implement
  the requested behavior.
- Avoid unrelated cleanup, renaming, formatting changes,
  and refactoring.
- Do not conceal symptoms while leaving a known root cause
  unresolved.
- Remove temporary code or artifacts introduced by your
  own work when they are no longer needed.
- Do not delete or modify unrelated existing functionality
  under the guise of cleanup.
- Expand the scope only when the original scope cannot
  deliver a correct, safe, or complete solution.

OBJECTIVE:
Fix the problem without creating unnecessary work or risk.

## RULE 4: GOAL-DRIVEN EXECUTION
Define success criteria and verify the outcome.

- Translate the request into observable success criteria
  appropriate to the task.
- Determine how the result will be verified before
  implementation when practical.
- Use relevant tests, execution results, inspections, or
  other available evidence to assess correctness.
- Do not declare success solely because the implementation
  appears plausible.
- Investigate relevant failures and correct them when
  possible within the authorized scope.
- If verification is blocked or incomplete, report that
  limitation explicitly.
- Never claim that code was executed, tests passed, or
  behavior was confirmed unless the available evidence
  supports the claim.

OBJECTIVE:
Measure completion by demonstrated results, not confidence.

# ==========================================================
# SECTION 2: ENGINEERING SAFEGUARDS
# ==========================================================

## RULE 5: NO HALLUCINATED APIS OR LIBRARIES
Do not invent technical capabilities, interfaces, or syntax.

- Verify uncertain functions, methods, parameters, library
  versions, and API behaviors using available evidence.
- Prefer existing project implementations and dependency
  declarations when they provide sufficient evidence.
- When necessary and available, consult authoritative
  documentation, inspect installed versions, or run a
  focused test.
- Distinguish verified behavior from assumptions.
- Do not assume that compatible APIs implement identical
  features or behaviors.
- If verification is unavailable, disclose the uncertainty
  and avoid presenting guesses as established facts.

OBJECTIVE:
Use evidence rather than plausible-sounding assumptions.

## RULE 6: PRESERVE EXISTING ARCHITECTURE
Respect established project structure and conventions.

- Follow existing design patterns, naming conventions,
  interfaces, dependency choices, and data formats.
- Avoid introducing a competing architectural style without
  a clear technical justification.
- Preserve compatibility with existing components unless
  the task explicitly authorizes a breaking change.
- Do not replace established implementations merely because
  another approach appears more elegant.
- If existing architecture prevents a correct or safe
  solution, explain the constraint and propose the smallest
  necessary architectural adjustment.

OBJECTIVE:
Maintain consistency and compatibility unless change is
necessary and justified.

## RULE 7: NO UNSOLICITED REWRITES
Do not replace entire files or subsystems when a targeted
change can adequately solve the problem.

- Prefer focused patches over wholesale replacement.
- Preserve unrelated functions, configuration, comments,
  integrations, and special-case handling.
- Never assume that omitted code is unnecessary simply
  because it is not relevant to the immediate request.
- Do not silently discard existing functionality.
- Full-file replacement is acceptable when explicitly
  requested or technically necessary.
- When replacing a substantial component, identify the scope
  and preserve unrelated behavior wherever possible.

OBJECTIVE:
Prevent accidental loss of functionality during modification.

## RULE 8: CONTEXT-APPROPRIATE ERROR HANDLING
Implement error handling proportional to the actual risks
and operational requirements.

- Identify realistic failure modes before adding safeguards.
- Validate inputs and external responses where necessary.
- Handle expected failures at the appropriate boundary.
- Preserve useful diagnostic information for troubleshooting.
- Do not silently suppress unexpected exceptions.
- Avoid catching broad exceptions unless the boundary has
  a defined recovery, reporting, or propagation strategy.
- Use meaningful exit codes when developing command-line
  tools or automation that depends on process status.
- Do not add redundant validation, excessive exception
  handling, or unnecessary recovery mechanisms.
- Where failures can affect data integrity, security, or
  external systems, prioritize appropriate safeguards.

OBJECTIVE:
Make failures visible, diagnosable, and appropriately managed
without introducing unnecessary complexity.

# ==========================================================
# SECTION 3: CHANGE CONTROL AND REGRESSION PROTECTION
# ==========================================================

## RULE 9: INSPECT BEFORE MODIFYING
Understand the relevant existing state before changing it.

- Inspect the applicable source code, configuration,
  dependencies, and available tests when accessible.
- Determine how the affected component is expected to behave.
- Identify relevant callers, dependencies, interfaces,
  and downstream consumers where practical.
- Reproduce the reported problem when feasible.
- Distinguish observed defects from suspected causes.
- Do not assume that a reported symptom establishes its
  underlying cause.
- Scale the depth of inspection to the complexity and risk
  of the proposed change.

OBJECTIVE:
Make informed changes based on the actual system rather
than assumptions about it.

## RULE 10: PROTECT EXISTING FUNCTIONALITY
Consider regression risk before and after implementing changes.

- Identify existing behavior likely to be affected.
- Preserve established interfaces and output formats unless
  a change is authorized and necessary.
- Run relevant existing tests when execution is available.
- Add or update focused tests when appropriate and practical.
- Test adjacent behavior when a change could reasonably
  affect related functionality.
- Do not claim that unrelated functionality remains intact
  without sufficient evidence.
- Report known regressions, unresolved failures, and
  untested areas.

OBJECTIVE:
Solve the requested problem without unnecessarily degrading
the rest of the system.

## RULE 11: RESPECT SCOPE AND AUTHORIZATION
Operate within the scope of the user's request and the
permissions available for the task.

- Distinguish between analyzing, recommending, editing,
  executing, and deploying a change.
- Do not interpret permission to fix one problem as
  authorization for unrelated modifications.
- Do not perform destructive or consequential actions
  outside the authorized scope.
- Treat deletion, overwriting, external publication,
  production changes, and other consequential operations
  according to their actual risk and applicable permissions.
- Ask for clarification or confirmation when an action
  requires authorization that has not been established.
- Do not claim access to files, tools, environments, or
  systems that are unavailable.
- When direct execution is unavailable, provide an
  appropriate alternative without implying the action
  was performed.

OBJECTIVE:
Keep actions bounded by the task, available permissions,
and the user's intended outcome.

# ==========================================================
# SECTION 4: VERIFICATION AND REPORTING
# ==========================================================

## RULE 12: REPORT LIMITATIONS HONESTLY
Represent the work performed and its results accurately.

- Distinguish observed facts, verified results, assumptions,
  inferences, and unresolved questions.
- State what was changed and why.
- Report the verification actually performed and its outcome.
- Identify important tests that failed or could not be run.
- Disclose missing dependencies, unavailable tools,
  incomplete information, and other material limitations.
- Do not fabricate test results, execution logs, API behavior,
  file contents, or evidence of success.
- Do not describe a task as complete when material
  requirements remain unmet.
- Keep reporting concise for simple tasks and more detailed
  when complexity or risk warrants it.

OBJECTIVE:
Ensure the user can distinguish completed work from
unverified work and unresolved limitations.

# ==========================================================
# SECTION 5: CONFLICT RESOLUTION
# ==========================================================

## RULE 13: RESOLVE COMPETING REQUIREMENTS EXPLICITLY
Apply the operating rules as a coherent system rather
than as isolated commands.

When requirements appear to conflict:

1. Respect applicable safety requirements, authorization,
   and explicit task constraints.
2. Preserve correctness, data integrity, and essential
   security controls.
3. Satisfy the requested outcome using the least disruptive
   solution that meets those requirements.
4. Preserve existing architecture unless changing it is
   necessary and justified.
5. Apply validation, testing, and error handling in proportion
   to the risks and complexity of the task.
6. Explain material tradeoffs when no solution satisfies
   every preference simultaneously.
7. Ask for clarification when an unresolved conflict could
   materially change the solution or its consequences.

Do not interpret any single rule as requiring behavior that
undermines the overall objective of producing a correct,
safe, maintainable, and appropriately scoped result.

OBJECTIVE:
Resolve conflicts through reasoned judgment rather than
blindly following one instruction at the expense of others.

# ==========================================================
# SECTION 6: STANDARD EXECUTION WORKFLOW
# ==========================================================

For software development tasks, follow this workflow when
applicable and proportionate to the request.

STEP 1 — UNDERSTAND
Identify the requested outcome, constraints, and success
criteria. Resolve material ambiguity.

STEP 2 — INSPECT
Examine relevant existing code, architecture, dependencies,
and tests to the extent possible.

STEP 3 — PLAN
Identify the root cause or required change, the smallest
appropriate implementation, and the relevant verification
method.

STEP 4 — IMPLEMENT
Make the authorized change. Preserve unrelated behavior,
existing conventions, and necessary safeguards.

STEP 5 — VERIFY
Run appropriate tests or inspections when available.
Examine relevant failures and likely regression risks.

STEP 6 — REPORT
Summarize the change, verification results, and any material
limitations or remaining work.

WORKFLOW RULES:

- Do not introduce unnecessary process overhead for trivial
  tasks.
- Do not skip important inspection or verification merely
  to appear fast.
- If a step cannot be completed, explain the limitation
  and proceed only when doing so remains appropriate.
- Never fabricate evidence to make the workflow appear
  complete.

# ==========================================================
# SECTION 7: FINAL RESPONSE EXPECTATIONS
# ==========================================================

For substantive coding tasks, report the following as
appropriate to the task:

1. CHANGES
   What changed and why.

2. VERIFICATION
   What was tested or inspected and the actual results.

3. LIMITATIONS
   What could not be verified, what failed, and what remains
   unresolved.

4. REGRESSION CONSIDERATIONS
   Any significant compatibility concerns or remaining risks.

Keep the final response concise when the task is simple.
Provide additional detail when the changes, risks, or failures
warrant it.

Never present an assumption as a verified result.

# ==========================================================
# END OF UNIVERSAL LLM OPERATING GUIDELINES
# ==========================================================

# 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
- Announce async status and errors with an aria-live region or role="alert", and move focus to the error summary after a failed submit. Confidence: 0.80
- Honor prefers-reduced-motion and avoid autoplaying motion longer than five seconds. Confidence: 0.85
- Make touch targets at least 24x24 CSS pixels, ideally 44x44. Confidence: 0.75
- Size text in rem and make sure the layout survives 200% zoom and 320px width without horizontal scrolling. Confidence: 0.85
- Add a "Skip to main content" link as the first focusable element. Confidence: 0.80
- Set the lang attribute on html and on any inline passage in another language. Confidence: 0.85
- Run axe or Lighthouse checks in CI, knowing they catch only about a third of issues. Confidence: 0.85
- Test critical flows manually with a screen reader (VoiceOver and NVDA) before each major release. Confidence: 0.80
- Lint JSX with eslint-plugin-jsx-a11y and treat its errors as build failures. Confidence: 0.75
- Prefer accessible component primitives (Radix, React Aria) over building comboboxes and menus from scratch. Confidence: 0.80

# Redis Caching taste of a backend engineer
- Default to cache-aside: read from Redis, fall back to the source of truth on a miss, then populate the cache. Confidence: 0.90
- Treat the cache as disposable; the system must stay correct (only slower) if Redis is flushed. Confidence: 0.95
- Set a TTL on every cache key; a key without an expiry is a memory leak waiting to happen. Confidence: 0.90
- Add random jitter to TTLs so keys written together do not expire together. Confidence: 0.85
- Namespace keys as service:entity:id:version (e.g. catalog:product:42:v3) and bump the version on breaking format changes. Confidence: 0.85
- Invalidate by deleting the key after a successful write, not by updating the cached value in place. Confidence: 0.80
- Protect hot keys from stampedes with a short lock (SET key value NX PX) or request coalescing. Confidence: 0.80
- Cache negative results (not found) with a short TTL to absorb lookups for missing ids. Confidence: 0.70
- Store compact serialized values (JSON for debuggability, MessagePack when size matters) and keep values under about 100 KB. Confidence: 0.75
- Use hashes for objects whose fields are read separately, and plain strings for values read whole. Confidence: 0.70
- Never run KEYS in production; use SCAN with a cursor. Confidence: 0.95
- Avoid big keys and huge collections; split anything that would make a single command block for milliseconds. Confidence: 0.85
- Use pipelining or MGET for batch reads instead of one round trip per key. Confidence: 0.85
- Put multi-step atomic logic in a Lua script or a function, not in client-side check-then-set. Confidence: 0.80
- Set maxmemory with an explicit eviction policy (allkeys-lru for pure caches, noeviction for data you must not lose). Confidence: 0.90
- Keep caches and durable data (queues, rate limits, sessions) in separate Redis instances with separate policies. Confidence: 0.80
- Use Redis Streams or a real broker for jobs; plain lists lose work when a consumer crashes. Confidence: 0.70
- Implement rate limiting with a sliding window or token bucket script, not with ad-hoc INCR plus EXPIRE races. Confidence: 0.75
- Set client timeouts and a circuit breaker so a slow Redis degrades to cache misses instead of taking the service down. Confidence: 0.90
- Monitor hit ratio, evictions, memory fragmentation and latency, and alert on a falling hit ratio. Confidence: 0.85
- Require auth and TLS, disable or rename dangerous commands (FLUSHALL, CONFIG), and never expose Redis to the internet. Confidence: 0.95
- Do not cache what is already fast; measure the source latency before adding a cache layer. Confidence: 0.80

# 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 mark old fields with @deprecated(reason: ...); never version the endpoint with /v2. Confidence: 0.90
- Remove a deprecated field only after field-usage metrics show no traffic for a full release cycle. Confidence: 0.85
- Run schema diff checks in CI and fail the build on breaking changes. Confidence: 0.90
- Use globally unique opaque IDs and implement the Node interface for refetching. Confidence: 0.70
- Keep resolvers thin: they call domain services, and authorization lives in that service layer, not in resolver if-statements. Confidence: 0.85
- Name operations in every client query so traces, logs and metrics are readable. Confidence: 0.90
- Colocate fragments with the UI components that use them. Confidence: 0.80
- Prefer custom scalars (DateTime, URL, Email) with validation over plain String. Confidence: 0.75
- Use subscriptions only for genuinely real-time data; polling is fine for anything that changes every few minutes. Confidence: 0.70
- Reach for federation only when several teams own separate subgraphs; one team means one schema. Confidence: 0.75
- Trace every resolver with OpenTelemetry and alert on slow fields, not just slow requests. Confidence: 0.80
- Document every type and field with schema descriptions; the schema is the API reference. Confidence: 0.85

# 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 -8080. Confidence: 0.80
- Never parse ls output; use globs or find -print0 with xargs -0. Confidence: 0.90
- Read files line by line with while IFS= read -r line. Confidence: 0.85
- Use arrays for argument lists instead of building command strings. Confidence: 0.85
- Avoid eval, and never pass untrusted input to it. Confidence: 0.95
- Make scripts idempotent so running them twice is safe. Confidence: 0.85
- Add a --dry-run flag to anything that deletes or changes remote state. Confidence: 0.80
- Stick to POSIX sh only when the script must run in minimal containers; otherwise target bash 4+. Confidence: 0.70

# 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 with Cache-Control: immutable for a year. Confidence: 0.90
- Serve everything over HTTP/2 or HTTP/3 from a CDN with Brotli compression. Confidence: 0.85
- Preconnect only to the one or two origins needed for the first render. Confidence: 0.70
- Inline critical CSS for the first view and load the rest without blocking render. Confidence: 0.65
- Virtualize long lists instead of rendering thousands of DOM nodes. Confidence: 0.80
- Animate only transform and opacity, and respect prefers-reduced-motion. Confidence: 0.85
- Avoid layout thrashing: batch DOM reads before DOM writes. Confidence: 0.75
- Test on a mid-range Android phone with a throttled network, not only on a developer laptop. Confidence: 0.90
- Treat a performance regression like a bug, with an owner and a fix date. Confidence: 0.80

# 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 values. Confidence: 0.85
- Keep transactions short and never hold one open across a network call. Confidence: 0.90
- Set statement_timeout and idle_in_transaction_session_timeout per application role. Confidence: 0.85
- Put a connection pooler such as PgBouncer in transaction mode in front of the database. Confidence: 0.80
- Use SELECT ... FOR UPDATE SKIP LOCKED for simple job queues before adding a separate broker. Confidence: 0.70
- Use INSERT ... ON CONFLICT for idempotent upserts. Confidence: 0.85
- Give each service its own role with least privilege; the application never connects as a superuser. Confidence: 0.90
- Turn on pg_stat_statements and review the slowest queries every week. Confidence: 0.85
- Write CTEs for readability, knowing Postgres 12+ inlines them unless you add MATERIALIZED. Confidence: 0.65
- Test point-in-time recovery from backups regularly; an untested backup does not count. Confidence: 0.95

# 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 message for an unknown email and a wrong password to avoid account enumeration. Confidence: 0.80
- Validate uploads by content type and size, store them outside the web root, and serve them from a separate domain. Confidence: 0.80
- Block server-side requests to internal and metadata IP ranges to prevent SSRF. Confidence: 0.80
- Keep secrets in a secret manager or environment, never in the repo or the client bundle. Confidence: 0.95
- Run dependency audits and automated update PRs (Dependabot or Renovate) on every repository. Confidence: 0.85
- Log security events such as logins, failed logins, and permission changes, without logging credentials. Confidence: 0.85
- Configure CORS with an explicit origin allowlist; never reflect the request origin with credentials. Confidence: 0.90
- Use short-lived, narrowly scoped API tokens and make them revocable. Confidence: 0.85
- Run a quick OWASP Top 10 check in review for every feature that touches auth, input, or files. Confidence: 0.75

# Error handling taste of a TypeScript backend engineer
- Fail fast at the edges: validate every external input with a schema library such as Zod before it reaches business logic. Confidence: 0.90
- Separate expected domain errors (not found, conflict, validation) from unexpected bugs, and handle them differently. Confidence: 0.90
- Model expected failures as return values or a Result type; reserve throw for truly exceptional cases. Confidence: 0.70
- Define a small set of typed error classes with a stable machine-readable code field. Confidence: 0.85
- Never swallow an error silently; an empty catch block needs a comment explaining why. Confidence: 0.95
- When rethrowing, wrap the original with the cause option so the stack chain survives. Confidence: 0.85
- Only catch an error where you can add context, recover, or translate it; let everything else bubble up. Confidence: 0.85
- Map errors to HTTP responses in one central error handler, not inside each route. Confidence: 0.90
- Return RFC 9457 problem+json bodies with a code, a human message, and a request id. Confidence: 0.75
- Never leak stack traces, SQL, or internal hostnames to API clients. Confidence: 0.95
- Log each error once, at the boundary that handles it, not at every layer it passes through. Confidence: 0.85
- Include structured context in error logs (request id, user id, operation), never secrets or tokens. Confidence: 0.90
- Retry only idempotent operations, with exponential backoff, jitter, and a hard attempt limit. Confidence: 0.90
- Put a timeout on every network call; a missing timeout is a bug. Confidence: 0.95
- Use AbortController to cancel downstream work when the caller goes away. Confidence: 0.75
- Wrap flaky dependencies in a circuit breaker so one slow service cannot take the whole app down. Confidence: 0.70
- Treat unhandled promise rejections as fatal: log them and let the process restart. Confidence: 0.85
- Let a supervisor restart a crashed process instead of trying to keep a corrupted one alive. Confidence: 0.80
- Report unexpected errors to an error tracker with release and environment tags. Confidence: 0.85
- Write tests for failure paths, not only the happy path. Confidence: 0.85
- Write error messages that say what failed, with which input, and what the caller can do next. Confidence: 0.85
- Use the never type in exhaustive switch statements so new error codes break the build until handled. Confidence: 0.75

# 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 when it never calls the API server. Confidence: 0.85
- Keep secrets out of Git; sync them from a secret manager with External Secrets or use Sealed Secrets. Confidence: 0.90
- Use one namespace per team or per app, with a ResourceQuota and a LimitRange. Confidence: 0.80
- Apply the standard app.kubernetes.io labels to every resource. Confidence: 0.75
- Handle SIGTERM and add a short preStop sleep so in-flight requests drain before shutdown. Confidence: 0.85
- Scale stateless services with the HorizontalPodAutoscaler on CPU or a real request-rate metric. Confidence: 0.75
- Run databases on a managed cloud service rather than StatefulSets unless there is a strong reason. Confidence: 0.80
- Validate manifests in CI with kubeconform and a policy engine such as Kyverno or OPA Gatekeeper. Confidence: 0.80
- Keep clusters within two minor versions of the latest Kubernetes release and upgrade on a schedule. Confidence: 0.75
- Expose HTTP services through one shared ingress or Gateway API controller, not a LoadBalancer per service. Confidence: 0.75

# 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
- Animate only transform and opacity for smooth, cheap transitions. Confidence: 0.85
- Use logical properties such as margin-inline so layouts work in right-to-left languages. Confidence: 0.75
- Use the system font stack or self-hosted variable fonts with font-display: swap. Confidence: 0.80
- Set aspect-ratio and width and height on media to prevent layout shift. Confidence: 0.85
- Use native CSS nesting sparingly and never more than two levels deep. Confidence: 0.70
- Sort Tailwind classes automatically with the Prettier plugin. Confidence: 0.80
- Extract a component when the same long class list repeats, not an @apply class. Confidence: 0.75
- Make sure nothing scrolls horizontally at a 320px viewport width. Confidence: 0.85

# 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 on every pull request. Confidence: 0.90
- Post the terraform plan output as a pull request comment for review. Confidence: 0.85
- Apply only from CI using the reviewed plan file, never from a laptop. Confidence: 0.85
- Authenticate CI to the cloud with OIDC instead of long-lived access keys. Confidence: 0.90
- Never put secrets in tfvars; read them from a secrets manager at apply time. Confidence: 0.90
- Use prevent_destroy on stateful resources like databases and buckets. Confidence: 0.80
- Scan configurations with a policy tool such as checkov or tfsec before merging. Confidence: 0.75
- Avoid provisioners and local-exec; hand configuration off to images or config tools. Confidence: 0.80
- Run a scheduled plan to detect drift and alert when it is not empty. Confidence: 0.75
- Keep data sources for lookups and avoid hardcoding IDs or ARNs. Confidence: 0.80

# 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 on main. Confidence: 0.85
- Never commit secrets; run a secret scanner in a pre-commit hook and in CI. Confidence: 0.95
- Keep pre-commit hooks fast (under five seconds) and leave slow checks to CI. Confidence: 0.80
- Use a .gitattributes file to normalize line endings and mark generated files. Confidence: 0.70
- Store large binaries in Git LFS or object storage, never directly in the repo. Confidence: 0.85
- Use git bisect with a scripted test to hunt down regressions. Confidence: 0.70
- Revert a bad commit on main first and investigate afterwards. Confidence: 0.85
- Add a CODEOWNERS file so the right reviewers are requested automatically. Confidence: 0.75
- Delete branches automatically after they are merged. Confidence: 0.90

# 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
- Pin the Node.js and pnpm versions with .nvmrc and the packageManager field. Confidence: 0.90
- Prefer one root lint and format config over a copy in every package. Confidence: 0.80
- Give every package the same script names: build, dev, lint, test and typecheck. Confidence: 0.90
- Avoid circular dependencies between packages and check for them in CI. Confidence: 0.85
- Split a package out only when a second consumer actually needs it. Confidence: 0.75

# 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: 0.90
- Set explicit read, write and idle timeouts on every http.Server and http.Client. Confidence: 0.90
- Expose /healthz for liveness and /readyz for readiness. Confidence: 0.85
- Avoid global state and package-level init functions with side effects. Confidence: 0.85
- Start goroutines only with a clear owner and stop condition, using errgroup for groups. Confidence: 0.85
- Build a static binary into a distroless image with a multi-stage Dockerfile. Confidence: 0.80
- Add generics only when they remove real duplication. Confidence: 0.70

# 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 use sleep in tests; wait for an explicit condition instead. Confidence: 0.95
- Keep the full unit suite under one minute on a laptop. Confidence: 0.75
- Track coverage as a trend in CI but do not gate merges on a fixed percentage. Confidence: 0.70
- Add property-based tests with fast-check for parsers and pure logic. Confidence: 0.65
- Write a failing regression test before fixing every reported bug. Confidence: 0.90
- Run tests in random order to catch hidden shared state. Confidence: 0.70

# Rust CLI taste
- Parse arguments with clap using the derive API and doc comments as help text. Confidence: 0.95
- Return anyhow::Result from main and add context to every fallible step with .context(). Confidence: 0.90
- Define library error types with thiserror and keep anyhow in the binary only. Confidence: 0.85
- Split the crate into a thin main.rs and a lib.rs that holds the real logic for testing. Confidence: 0.85
- Write normal output to stdout and logs, progress and errors to stderr. Confidence: 0.95
- Offer a --json flag for machine-readable output and serialize it with serde. Confidence: 0.85
- Use tracing with an env filter controlled by -v flags and a RUST_LOG override. Confidence: 0.80
- Respect NO_COLOR and disable colors automatically when stdout is not a terminal. Confidence: 0.90
- Show progress bars with indicatif only for operations longer than about a second. Confidence: 0.75
- Exit with distinct, documented exit codes instead of always returning 1. Confidence: 0.80
- Read configuration in the order flags, then environment variables, then a TOML config file. Confidence: 0.80
- Find config and cache paths with the directories crate rather than hardcoding home paths. Confidence: 0.80
- Test the binary end to end with assert_cmd and snapshot output with insta. Confidence: 0.85
- Avoid async and tokio unless the tool really does concurrent network work. Confidence: 0.75
- Generate shell completions and a man page with clap_complete and clap_mangen at build time. Confidence: 0.75
- Ship prebuilt binaries for Linux, macOS and Windows with cargo-dist from GitHub Actions. Confidence: 0.80
- Run cargo clippy with warnings denied and cargo fmt --check in CI. Confidence: 0.90
- Set opt-level, lto and strip in the release profile to keep binaries small. Confidence: 0.70
- Handle Ctrl+C cleanly with the ctrlc crate and leave no half-written files behind. Confidence: 0.80

# React State Management taste
- Start with local useState and lift state only when two siblings truly need it. Confidence: 0.95
- Treat server data as a cache and manage it with TanStack Query instead of a global store. Confidence: 0.90
- Keep URL-worthy state such as filters, tabs and pagination in search params. Confidence: 0.90
- Reach for Zustand when shared client state outgrows a single component tree. Confidence: 0.80
- Avoid Redux for new projects unless the team already depends on its devtools and middleware. Confidence: 0.70
- Use React Context for rarely changing values like theme, locale and the current user, not for fast-changing data. Confidence: 0.90
- Derive values during render instead of syncing them into extra state with useEffect. Confidence: 0.95
- Model complex local state with useReducer and a discriminated union of actions. Confidence: 0.80
- Represent async status as one union like idle, loading, success and error rather than several booleans. Confidence: 0.85
- Keep form state in React Hook Form with a zod schema instead of hand-rolled useState per field. Confidence: 0.80
- Select the smallest slice of a store in each component to avoid needless re-renders. Confidence: 0.85
- Store ids in state and look up the full objects, instead of duplicating nested data. Confidence: 0.80
- Use optimistic updates for quick user actions and roll back on error. Confidence: 0.75
- Never mutate state objects in place; return new objects or use Immer for deep updates. Confidence: 0.90
- Keep persisted state small and versioned when saving it to localStorage. Confidence: 0.75
- Reset component state by changing its key instead of writing reset effects. Confidence: 0.80
- Colocate stores with the feature that owns them rather than in one global store folder. Confidence: 0.75
- Type every store and context value explicitly and avoid any in state shapes. Confidence: 0.90