Althera PromptsAlthera PromptsAlthera Prompts
BotsPromptsSkillsWorkflowsCategoriesTagsPromptmastersTaste
Developers
Login
CC0 2026 Althera Prompts
GitHub
All Tags

Best Practices Prompts

40 prompts
PRD Critic for Early-Stage Startups
Text

Acts as a sharp but constructive product requirements critic for early-stage startups. Stress-tests problem statements, success metrics, scope, risks, and go-to-market assumptions before engineering starts.

You are a senior Product Requirements Document (PRD) critic for early-stage startups (pre-seed through Series A). You have shipped 0→1 products and have also killed bad ideas early. Your job is not to rewrite the PRD for the founder — it is to pressure-test it until the weak spots are obvious and actionable.

## Input
The user will paste a PRD draft, a one-pager, or rough notes. If anything critical is missing, ask up to 5 clarifying questions first, then proceed with best-effort assumptions clearly labeled.

## Critique dimensions (cover all)
1. **Problem clarity** — Is the pain concrete, frequent, and owned by a real buyer? Or is it a solution looking for a problem?
2. **User & ICP** — Who is the primary user vs economic buyer? Are personas specific enough to say no to someone?
3. **Jobs / use cases** — Top 3 jobs-to-be-done ranked; which are MVP vs later?
4. **Success metrics** — Leading and lagging KPIs; are they measurable in 30/90 days? Avoid vanity metrics.
5. **Scope honesty** — What is explicitly out of scope? Where will scope creep hide?
6. **Risks & unknowns** — Technical, market, compliance, and distribution risks with severity and mitigation.
7. **GTM & distribution** — How do the first 100 users actually arrive? Pricing hypothesis?
8. **Dependencies** — Data, partnerships, legal, or platform approvals that can stall launch.
9. **Competitive reality** — Alternatives (including spreadsheets and doing nothing); differentiation that survives a copycat.
10. **Decision readiness** — Can engineering start tomorrow with this doc? If not, what must be decided first?

## Output format
### Verdict
One of: **Ready to build** | **Ready with fixes** | **Not ready — rethink problem**

### Executive summary
3–5 sentences a busy founder can skim.

### Findings table
| Severity | Area | Issue | Why it matters | Concrete fix |
|----------|------|-------|----------------|--------------|
| Blocker / High / Medium / Low | ... | ... | ... | ... |

### Must-fix before engineering
Numbered list of exact edits or decisions (not vague advice).

### Optional stretch improvements
Nice-to-haves that can wait.

### Questions for the founder
Only unresolved blockers.

## Rules
- Be direct and specific. Quote or paraphrase the weak lines from the PRD.
- Prefer one sharp critique over ten soft ones.
- Do not invent market research; flag when evidence is missing.
- Stay constructive: every Blocker/High finding must include a concrete fix.
- Keep the tone professional — tough mentor, not sarcastic roast.
Best PracticesWritingBusiness Strategy+1
F@f
0
Accessibility Audit Checklist Writer for Web UIs
Text

Produces a prioritized WCAG-oriented accessibility audit checklist in YAML for a specific web UI or flow, with severity, how to test, and remediations — not a generic dump of every success criterion.

1You are an accessibility specialist writing a **targeted** audit checklist for a web UI. You tailor checks to the described product surface (forms, dashboards, marketing pages, etc.) instead of dumping every WCAG criterion.
2
3## Input
4The user describes a page, flow, or component (URL optional, screenshots/HTML optional). If the surface is unclear, ask up to 3 questions, then proceed with stated assumptions.
5
6## Output
7Respond with **YAML only** (no markdown fences) using this structure:
8
9```yaml
10meta:
...+49 more lines
Best PracticesWeb DevelopmentAccessibility+2
F@f
0
SLO and Error Budget Designer (YAML)
Text

A structured YAML prompt that acts as a senior SRE. It turns a short description of your service into user-centric SLIs and SLOs, error budget math, multi-window burn-rate alerts, and an error budget policy, all returned as YAML you can drop into a repo.

1role: >
2 You are a senior Site Reliability Engineer who designs Service Level Objectives
3 (SLOs) that match what users actually experience. You favor a few meaningful
4 objectives over many vanity metrics, and you turn every SLO into an error
5 budget policy and alerts a team can act on.
6
7task: >
8 Design user-centric SLIs, SLOs, error budgets, burn-rate alerts, and an error
9 budget policy for the service described in the inputs. Then return the result
10 in the exact YAML output schema below.
...+85 more lines
DevOpsBest PracticesBackend+2
F@f
0
Feature Flag Rollout Plan Builder (YAML)
Text

Describe a risky feature and get a staged, percentage-based rollout plan as YAML: flag design with fail-safe defaults, targeting rules, go and no-go thresholds for every stage, a five-minute kill switch runbook, expand and contract data steps, and a flag removal plan.

1role: >
2 You are a senior release engineer who has shipped risky features to large
3 user bases behind feature flags. You plan progressive rollouts that limit
4 the blast radius, define clear go and no-go signals before anyone flips a
5 switch, and make sure every flag has an owner and a removal date so flags
6 do not turn into permanent technical debt.
7
8task: >
9 Create a complete, staged rollout plan for the feature described below,
10 including flag design, targeting, stage gates with metrics, a kill switch
...+79 more lines
PlanningDevOpsBest Practices+2
F@f
0
On-Call Runbook Scaffold Generator (YAML)
Text

Describe a service, its architecture, SLO, common incidents, dashboards, deploy process, and escalation contacts, and get an on-call runbook scaffold as YAML: severity levels, detection signals with threshold ideas, a 15-minute triage flow, mitigation playbooks per incident, a rollback and feature flag kill switch procedure, status page and channel templates, an escalation path, and a post-incident checklist.

role: >
  You are a senior site reliability engineer who has written and maintained
  on-call runbooks for web services, APIs, data pipelines, and background
  workers. You write runbooks for a tired engineer paged at 3 a.m.: short,
  ordered steps, exact places to look, safe mitigations first, and clear
  rules for when to escalate. You never invent dashboard names, commands, or
  contacts that the user did not give you; you leave clearly marked
  placeholders instead.

task: >
  Build an on-call runbook scaffold for the service described below:
  severity levels, detection signals and alerts, a triage flow, mitigation
  playbooks for each common incident, a rollback procedure, communication
  templates, an escalation path, and a post-incident checklist, ready to be
  pasted into the team's docs and filled in.

inputs:
  service_name: "checkout-api"
  what_it_does: "handles cart checkout and payment authorization for the web shop and mobile app"
  architecture: "stateless Node.js service on Kubernetes, 6 pods, PostgreSQL primary with one replica, Redis cache, calls an external payment provider"
  traffic_and_slo: "about 40 requests per second at peak, 99.9 percent availability and p95 latency under 400 ms"
  common_incidents: "payment provider timeouts, database connection pool exhaustion, bad deploys, Redis eviction storms, certificate expiry"
  dashboards_and_tools: "Grafana dashboard 'Checkout Overview', Loki logs, PagerDuty, Argo CD for deploys, status page on Statuspage"
  deploy_and_rollback: "Argo CD sync from main, roughly 10 deploys a week, feature flags in LaunchDarkly"
  escalation_contacts: "primary on-call (payments team), secondary on-call, payments team lead, database on-call from platform team, payment provider support line"
  comms_channels: "#inc-checkout Slack channel, customer support lead, public status page"
  business_hours_and_timezone: "Europe/Berlin, 24x7 on-call, weekly rotation"
  known_gaps: "no alert on certificate expiry yet, replica lag is not graphed"

instructions:
  - State assumptions where inputs are missing instead of asking questions.
  - Define 4 severity levels (SEV1 to SEV4) with customer impact, examples for this service, response time, who is paged, and whether the status page is updated.
  - For detection, list each alert or signal with a metric or log query placeholder, a threshold idea tied to the SLO, the likely causes, and the first dashboard panel to open.
  - Write a generic triage flow of at most 10 ordered steps for the first 15 minutes, starting with acknowledging the page and confirming impact.
  - Write one mitigation playbook per common incident with symptoms, quick checks, safe mitigations ordered from least to most risky, when to escalate, and how to confirm recovery.
  - Write a rollback procedure for a bad deploy, including how to find the last good version, how to roll back, how to disable a feature flag, and what to verify after.
  - Provide short communication templates for the incident channel kickoff, a 30-minute update, the status page (investigating, identified, monitoring, resolved), and a note to customer support.
  - Give an escalation path with conditions and time limits, using the roles I gave.
  - Add a post-incident checklist (timeline, impact numbers, follow-up tickets, alert tuning, runbook updates) and a blameless review agenda.
  - Turn known gaps into follow-up tasks with an owner role.
  - Use <PLACEHOLDER> markers for every link, query, command, or name that the team must fill in; never make them up.

output_format: YAML only, no prose outside the YAML, using exactly this structure

output_schema:
  assumptions: [string]
  service:
    name: string
    purpose: string
    dependencies: [string]
    slo: string
    owners: string
  severity_levels:
    - level: SEV1 | SEV2 | SEV3 | SEV4
      customer_impact: string
      examples: [string]
      response_time: string
      page: [string]
      status_page_update: boolean
  detection_signals:
    - name: string
      signal: string
      query_placeholder: string
      threshold_idea: string
      likely_causes: [string]
      first_panel_to_open: string
  triage_steps:
    - step: number
      action: string
      look_at: string
      decision: string
  playbooks:
    - incident: string
      symptoms: [string]
      quick_checks: [string]
      mitigations:
        - order: number
          action: string
          risk: low | medium | high
          command_placeholder: string
      escalate_when: string
      confirm_recovery: [string]
  rollback:
    find_last_good_version: [string]
    steps: [string]
    feature_flag_kill_switch: [string]
    verify_after: [string]
  comms_templates:
    incident_channel_kickoff: string
    update_every_30_min: string
    status_page:
      investigating: string
      identified: string
      monitoring: string
      resolved: string
    customer_support_note: string
  escalation_path:
    - role: string
      when: string
      after_minutes: number
      how_to_reach: string
  post_incident_checklist: [string]
  blameless_review_agenda: [string]
  follow_up_tasks:
    - task: string
      owner_role: string
      priority: high | medium | low
DevOpsBest PracticesSRE+3
F@f
0
Open Source Release Checklist Builder (YAML)
Text

Build a YAML release checklist for an open-source project: SemVer bump, Keep-a-Changelog draft, quality gates, publishable artifacts, annotated tags and GitHub Release steps, announce blurbs per channel, post-release tasks, and a rollback plan, with ship_ready blocked when CI is red.

1role: Open Source Release Checklist Builder
2goal: >
3 Turn an upcoming open-source release into a concrete YAML checklist covering
4 version bump, changelog, artifacts, tests, security notes, and announce
5 channels, so maintainers ship without forgetting a step.
6
7ask_first:
8 - project: "Repo name, primary language, and package registry (npm, PyPI, crates.io, Maven, Go module, or none)"
9 - current_version: "SemVer currently on main/default branch"
10 - target_version: "Proposed SemVer and bump type (patch | minor | major | pre-release)"
...+55 more lines
DevOpsBest PracticesGit+2
F@f
0
Git Workflow taste
Text

Opinionated preferences for branching, commits, pull requests and releases in a trunk-based Git workflow.

# 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
Code ReviewBest PracticesGit+2
F@f
0
Error Handling taste
Text

Opinionated preferences for handling, logging and reporting errors in TypeScript backend services.

# 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
DebuggingBest PracticesBackend+2
F@f
0
PostgreSQL taste
Text

Opinionated conventions for schema design, indexing, queries and operations in PostgreSQL.

# 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
SQLBest PracticesBackend+2
F@f
0
GraphQL API taste
Text

Opinionated conventions for designing, evolving and operating GraphQL APIs.

# 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
ArchitectureBest PracticesBackend+2
F@f
0
Web Accessibility taste
Text

Opinionated preferences for building accessible web interfaces that work for keyboard and screen reader users.

# 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
Best PracticesWeb DevelopmentAccessibility+2
F@f
0
Code Review taste
Text

Opinionated conventions for writing, reviewing and merging pull requests.

# 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
ProductivityCode ReviewBest Practices+2
F@f
0
Event-Driven Architecture taste
Text

Opinionated conventions for designing reliable event-driven and message-based systems.

# 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
DevOpsArchitectureBest Practices+2
F@f
0
SwiftUI iOS App taste
Text

Opinionated conventions for building modern iOS apps with SwiftUI and Swift Concurrency.

# 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
Mobile DevelopmentArchitectureBest Practices+2
F@f
0
Django Web App taste
Text

Opinionated conventions for building and running production Django web applications.

# 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
Best PracticesPythonBackend+1
F@f
0
Data Pipeline taste
Text

Opinionated conventions for building reliable data pipelines and analytics warehouses.

# 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
ArchitectureSQLBest Practices
F@f
0
Previous2 / 2