constellai 0.3.0

package/skills/design/web-composition-standards-playbook/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: web-composition-standards-playbook
+description: |
+  Use this skill when Codex needs web design guidelines and standards by the Vercel engineering team. Covers layout, typography, color, motion, and accessibility for product UI. Recast from the original web-design-guidelines/SKILL.md material as the web-composition-standards-playbook procedure.
+---
+
+# Web Composition Standards Playbook
+
+## Role
+
+Use this skill when Codex needs web design guidelines and standards by the Vercel engineering team. Covers layout, typography, color, motion, and accessibility for product UI. Recast from the original web-design-guidelines/SKILL.md material as the web-composition-standards-playbook procedure.
+
+## Source Trace
+
+- Original Markdown: `web-design-guidelines/SKILL.md`
+- Reformulated skill name: `web-composition-standards-playbook`
+- Upstream reference: https://github.com/vercel-labs/skills
+- Source category: `design-systems`
+
+## Operating Guidance
+
+Follow the rewritten material below as the working procedure. Keep code blocks, commands, file paths, URLs, dimensions, and API names exact when applying the skill.
+
+> Adapted from the Vercel engineering team.
+
+## Purpose
+
+Web design guidelines and standards by the Vercel engineering team. Covers layout, typography, color, motion, and accessibility for product UI.
+
+## Origin
+
+- Upstream: https://github.com/vercel-labs/skills
+- Category: `design-systems`
+
+## Procedure
+
+This catalogue entry advertises the skill in Open Design so the agent
+discovers it during planning. To execute the full upstream workflow with
+its original assets, scripts, and references, install the upstream
+bundle into your active agent's skills directory:
+
+```bash
+# Inspect the upstream README for exact paths
+open https://github.com/vercel-labs/skills
+```
+
+Then request this skill by name (`web-design-guidelines`) or with
+one of the trigger phrases listed in this skill's frontmatter.

package/skills/design/web-deliverables-assembler-playbook/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: web-deliverables-assembler-playbook
+description: |
+  Use this skill when Codex needs assemble complex claude.ai HTML artifacts with React and Tailwind. Anthropic's reference workflow for shipping rich, embeddable artifacts. Recast from the original web-artifacts-builder/SKILL.md material as the web-deliverables-assembler-playbook procedure.
+---
+
+# Web Deliverables Assembler Playbook
+
+## Role
+
+Use this skill when Codex needs assemble complex claude.ai HTML artifacts with React and Tailwind. Anthropic's reference workflow for shipping rich, embeddable artifacts. Recast from the original web-artifacts-builder/SKILL.md material as the web-deliverables-assembler-playbook procedure.
+
+## Source Trace
+
+- Original Markdown: `web-artifacts-builder/SKILL.md`
+- Reformulated skill name: `web-deliverables-assembler-playbook`
+- Upstream reference: https://github.com/anthropics/skills/tree/main/skills/web-artifacts-builder
+- Source category: `web-artifacts`
+
+## Operating Guidance
+
+Follow the rewritten material below as the working procedure. Keep code blocks, commands, file paths, URLs, dimensions, and API names exact when applying the skill.
+
+> Adapted from Anthropic's official skills repository.
+
+## Purpose
+
+Assemble complex claude.ai HTML artifacts with React and Tailwind. Anthropic's reference workflow for shipping rich, embeddable artifacts.
+
+## Origin
+
+- Upstream: https://github.com/anthropics/skills/tree/main/skills/web-artifacts-builder
+- Category: `web-artifacts`
+
+## Procedure
+
+This catalogue entry advertises the skill in Open Design so the agent
+discovers it during planning. To execute the full upstream workflow with
+its original assets, scripts, and references, install the upstream
+bundle into your active agent's skills directory:
+
+```bash
+# Inspect the upstream README for exact paths
+open https://github.com/anthropics/skills/tree/main/skills/web-artifacts-builder
+```
+
+Then request this skill by name (`web-artifacts-builder`) or with
+one of the trigger phrases listed in this skill's frontmatter.

package/skills/design/word-playbook/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: word-playbook
+description: |
+  Use this skill when Codex needs produce, edit, and analyze Word documents with tracked changes, comments, and formatting. Helpful for design briefs, copy docs, and review-ready deliverables. Recast from the original docx/SKILL.md material as the word-playbook procedure.
+---
+
+# Word Playbook
+
+## Role
+
+Use this skill when Codex needs produce, edit, and analyze Word documents with tracked changes, comments, and formatting. Helpful for design briefs, copy docs, and review-ready deliverables. Recast from the original docx/SKILL.md material as the word-playbook procedure.
+
+## Source Trace
+
+- Original Markdown: `docx/SKILL.md`
+- Reformulated skill name: `word-playbook`
+- Upstream reference: https://github.com/anthropics/skills/tree/main/skills/docx
+- Source category: `documents`
+
+## Operating Guidance
+
+Follow the rewritten material below as the working procedure. Keep code blocks, commands, file paths, URLs, dimensions, and API names exact when applying the skill.
+
+> Adapted from Anthropic's official skills repository.
+
+## Purpose
+
+Produce, edit, and analyze Word documents with tracked changes, comments, and formatting. Helpful for design briefs, copy docs, and review-ready deliverables.
+
+## Origin
+
+- Upstream: https://github.com/anthropics/skills/tree/main/skills/docx
+- Category: `documents`
+
+## Procedure
+
+This catalogue entry advertises the skill in Open Design so the agent
+discovers it during planning. To execute the full upstream workflow with
+its original assets, scripts, and references, install the upstream
+bundle into your active agent's skills directory:
+
+```bash
+# Inspect the upstream README for exact paths
+open https://github.com/anthropics/skills/tree/main/skills/docx
+```
+
+Then request this skill by name (`docx`) or with
+one of the trigger phrases listed in this skill's frontmatter.

package/skills/design/workspace-composition-playbook/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: workspace-composition-playbook
+description: |
+  Use this skill when Codex needs produce beautiful visual art in PNG and PDF documents using design philosophy and aesthetic principles for posters, illustrations, and static pieces. Recast from the original canvas-design/SKILL.md material as the workspace-composition-playbook procedure.
+---
+
+# Workspace Composition Playbook
+
+## Role
+
+Use this skill when Codex needs produce beautiful visual art in PNG and PDF documents using design philosophy and aesthetic principles for posters, illustrations, and static pieces. Recast from the original canvas-design/SKILL.md material as the workspace-composition-playbook procedure.
+
+## Source Trace
+
+- Original Markdown: `canvas-design/SKILL.md`
+- Reformulated skill name: `workspace-composition-playbook`
+- Upstream reference: https://github.com/anthropics/skills/tree/main/skills/canvas-design
+- Source category: `image-generation`
+
+## Operating Guidance
+
+Follow the rewritten material below as the working procedure. Keep code blocks, commands, file paths, URLs, dimensions, and API names exact when applying the skill.
+
+> Adapted from Anthropic's official skills repository.
+
+## Purpose
+
+Produce beautiful visual art in PNG and PDF documents using design philosophy and aesthetic principles for posters, illustrations, and static pieces.
+
+## Origin
+
+- Upstream: https://github.com/anthropics/skills/tree/main/skills/canvas-design
+- Category: `image-generation`
+
+## Procedure
+
+This catalogue entry advertises the skill in Open Design so the agent
+discovers it during planning. To execute the full upstream workflow with
+its original assets, scripts, and references, install the upstream
+bundle into your active agent's skills directory:
+
+```bash
+# Inspect the upstream README for exact paths
+open https://github.com/anthropics/skills/tree/main/skills/canvas-design
+```
+
+Then request this skill by name (`canvas-design`) or with
+one of the trigger phrases listed in this skill's frontmatter.

package/skills/design/wpds-playbook/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: wpds-playbook
+description: |
+  Use this skill when Codex needs wordPress Design System. Apply WordPress's official design tokens, typography, and component patterns to themes and sites. Recast from the original wpds/SKILL.md material as the wpds-playbook procedure.
+---
+
+# Wpds Playbook
+
+## Role
+
+Use this skill when Codex needs wordPress Design System. Apply WordPress's official design tokens, typography, and component patterns to themes and sites. Recast from the original wpds/SKILL.md material as the wpds-playbook procedure.
+
+## Source Trace
+
+- Original Markdown: `wpds/SKILL.md`
+- Reformulated skill name: `wpds-playbook`
+- Upstream reference: https://github.com/WordPress/skills
+- Source category: `design-systems`
+
+## Operating Guidance
+
+Follow the rewritten material below as the working procedure. Keep code blocks, commands, file paths, URLs, dimensions, and API names exact when applying the skill.
+
+> Adapted from the WordPress development team.
+
+## Purpose
+
+WordPress Design System. Apply WordPress's official design tokens, typography, and component patterns to themes and sites.
+
+## Origin
+
+- Upstream: https://github.com/WordPress/skills
+- Category: `design-systems`
+
+## Procedure
+
+This catalogue entry advertises the skill in Open Design so the agent
+discovers it during planning. To execute the full upstream workflow with
+its original assets, scripts, and references, install the upstream
+bundle into your active agent's skills directory:
+
+```bash
+# Inspect the upstream README for exact paths
+open https://github.com/WordPress/skills
+```
+
+Then request this skill by name (`wpds`) or with
+one of the trigger phrases listed in this skill's frontmatter.

package/skills/design/youtube-clipper-playbook/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: youtube-clipper-playbook
+description: |
+  Use this skill when Codex needs youTube clip generation and editing with automated workflows — pull source video, slice highlights, add captions, and export. Recast from the original youtube-clipper/SKILL.md material as the youtube-clipper-playbook procedure.
+---
+
+# Youtube Clipper Playbook
+
+## Role
+
+Use this skill when Codex needs youTube clip generation and editing with automated workflows — pull source video, slice highlights, add captions, and export. Recast from the original youtube-clipper/SKILL.md material as the youtube-clipper-playbook procedure.
+
+## Source Trace
+
+- Original Markdown: `youtube-clipper/SKILL.md`
+- Reformulated skill name: `youtube-clipper-playbook`
+- Upstream reference: https://github.com/op7418/Youtube-clipper-skill
+- Source category: `video-generation`
+
+## Operating Guidance
+
+Follow the rewritten material below as the working procedure. Keep code blocks, commands, file paths, URLs, dimensions, and API names exact when applying the skill.
+
+> Adapted from @op7418.
+
+## Purpose
+
+YouTube clip generation and editing with automated workflows — pull source video, slice highlights, add captions, and export.
+
+## Origin
+
+- Upstream: https://github.com/op7418/Youtube-clipper-skill
+- Category: `video-generation`
+
+## Procedure
+
+This catalogue entry advertises the skill in Open Design so the agent
+discovers it during planning. To execute the full upstream workflow with
+its original assets, scripts, and references, install the upstream
+bundle into your active agent's skills directory:
+
+```bash
+# Inspect the upstream README for exact paths
+open https://github.com/op7418/Youtube-clipper-skill
+```
+
+Then request this skill by name (`youtube-clipper`) or with
+one of the trigger phrases listed in this skill's frontmatter.

package/skills/engineering/architecture/api-design-rest-graphql/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: api-design-rest-graphql
+description: REST design grounded in HTTP semantics (methods, status, idempotency) and GraphQL schema/query design; read when designing or reviewing an API.
+domain: engineering
+category: architecture
+tags: [api-design, rest, graphql, http, schema]
+official_sources:
+  - https://www.rfc-editor.org/rfc/rfc9110.html
+  - https://graphql.org/learn/
+verified: 2026-06-16
+---
+
+# API Design: REST & GraphQL
+
+## Overview
+This skill covers two dominant API styles: REST, which builds on the standardized semantics of HTTP (methods, status codes, idempotency), and GraphQL, where clients request exactly the data they need against a typed schema. Read it when designing endpoints, choosing between the styles, or reviewing API contracts for correctness and consistency.
+
+## Official sources
+- RFC 9110 — HTTP Semantics (methods, status codes, safe/idempotent): https://www.rfc-editor.org/rfc/rfc9110.html
+- GraphQL — official Learn guide: https://graphql.org/learn/
+
+## Core concepts
+- **HTTP methods (RFC 9110 §9)**: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE — each with defined semantics; map resource operations onto them rather than inventing verbs.
+- **Safe and idempotent methods**: safe methods (e.g. GET, HEAD) are not expected to change server state; idempotent methods (GET, HEAD, PUT, DELETE, etc.) produce the same effect whether sent once or many times — essential for safe retries.
+- **Status codes (RFC 9110 §15)**: five classes — 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error — communicate outcome semantically.
+- **GraphQL schema and types**: the schema's type system describes exactly what data can be queried; the schema is the contract between client and server.
+- **GraphQL operations**: queries read data, mutations modify data, and subscriptions stream updates; clients select precisely the fields they need.
+- **GraphQL resolvers**: each field is backed by a resolver function that produces its value during execution.
+
+## Best practices
+- Honor HTTP semantics: use idempotent methods (PUT/DELETE) where clients may retry, and return status codes that match the actual outcome (per RFC 9110).
+- Use GET only for safe, side-effect-free reads so caches and crawlers can call it without changing state.
+- In GraphQL, design the schema around domain types and let clients select fields; avoid one-off endpoints — the schema is the single contract.
+- Version and evolve deliberately: REST via URL/media-type versioning; GraphQL by adding fields and deprecating rather than breaking existing ones.
+
+## Common pitfalls
+- Using POST (or GET) for everything in REST → breaks idempotency and caching; pick the method that matches the operation's semantics.
+- Returning 200 OK with an error body → clients and proxies cannot react correctly; use the appropriate 4xx/5xx status.
+- Exposing unbounded GraphQL queries → deep/nested queries can overload the server; add depth/complexity limits and pagination.
+
+## Examples
+```http
+# REST — idempotent update via PUT
+PUT /users/42 HTTP/1.1
+Content-Type: application/json
+
+{ "name": "Ada", "email": "ada@example.com" }
+# -> 200 OK (updated) or 201 Created; repeating yields the same result
+```
+```graphql
+# GraphQL — client selects exactly the fields it needs
+query {
+  user(id: "42") {
+    name
+    email
+  }
+}
+```
+
+## Further reading
+- GraphQL best practices (pagination, versioning, nullability): https://graphql.org/learn/best-practices/
+- RFC 9110 method definitions (Section 9): https://www.rfc-editor.org/rfc/rfc9110.html#name-methods
+
+## Related skills
+- ../software-architecture-patterns — where APIs sit in service boundaries
+- ../caching-strategies — HTTP caching and cache-aside for API responses
+- ../data-modeling — shaping resources and types behind the API

package/skills/engineering/architecture/caching-strategies/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: caching-strategies
+description: Cache layers, cache-aside, TTLs, and invalidation to cut latency and load; read before adding a cache or debugging stale data.
+domain: engineering
+category: architecture
+tags: [caching, cache-aside, ttl, invalidation, redis]
+official_sources:
+  - https://aws.amazon.com/caching/
+  - https://redis.io/docs/latest/develop/
+verified: 2026-06-16
+---
+
+# Caching Strategies
+
+## Overview
+A cache is a high-speed storage layer that holds a subset of data so future reads are served from fast memory (often sub-millisecond) instead of a slower origin. Caching reduces latency and offloads databases and services, but introduces the hard problems of staleness and invalidation. Read this before adding a cache layer or diagnosing stale/inconsistent reads.
+
+## Official sources
+- AWS — Caching Overview (layers, TTLs, CDN, in-memory): https://aws.amazon.com/caching/
+- Redis — Develop documentation (data types, clients, pub/sub): https://redis.io/docs/latest/develop/
+
+## Core concepts
+- **What a cache is**: a high-speed layer storing a subset of data; reading from an in-memory cache is extremely fast (sub-millisecond) compared with the origin store.
+- **Cache layers**: caching happens at multiple tiers — CDN/edge for static content, application/in-memory caches (e.g. Redis) for data and sessions, and database/query caches.
+- **Cache-aside (lazy loading)**: the application checks the cache first; on a miss it loads from the origin, populates the cache, and returns — only requested data is ever cached.
+- **TTL (time to live)**: an expiry applied to cached entries so stale data is automatically evicted after a bounded window.
+- **CDN / edge caching**: a CDN serves cached copies of content (pages, images, video) from a global network of edge locations near users.
+- **Eviction**: when memory is full, caches evict entries by policy (e.g. LRU) to make room for new data.
+
+## Best practices
+- Set a TTL on cached entries so staleness is bounded even when explicit invalidation is missed (AWS recommends TTLs to expire data appropriately).
+- Use cache-aside as the default for read-heavy data: load on demand and cache only what is actually requested.
+- Cache at the right layer: CDN for static assets, in-memory (Redis) for hot data and sessions, closest to where the read happens.
+- Invalidate or update the cache on writes (write-through or explicit delete) to limit how long stale data can be served.
+
+## Common pitfalls
+- Caching with no TTL and no invalidation → data silently goes stale forever; always bound freshness.
+- Cache stampede: many concurrent misses hit the origin at once when a hot key expires → use locking/single-flight or staggered/jittered TTLs.
+- Caching user-specific or sensitive data in a shared/edge cache → leaks across users; scope cache keys and mark private responses appropriately.
+
+## Examples
+```text
+Cache-aside read path:
+  1. value = cache.get(key)
+  2. if hit: return value
+  3. value = db.query(...)        # miss
+  4. cache.set(key, value, TTL)   # populate with expiry
+  5. return value
+# On write: db.update(...); cache.del(key)  (or update in place)
+```
+
+## Further reading
+- Redis develop docs (clients, data types, pub/sub): https://redis.io/docs/latest/develop/
+- AWS caching overview (database, session, API caching): https://aws.amazon.com/caching/
+
+## Related skills
+- ../system-design-fundamentals — latency/throughput trade-offs caching addresses
+- ../api-design-rest-graphql — HTTP caching of API responses
+- ../scalability-reliability — caching to offload origins under load

package/skills/engineering/architecture/data-modeling/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: data-modeling
+description: Relational and document data modeling — tables, keys, constraints, normalization, and when to denormalize; read before designing a schema.
+domain: engineering
+category: architecture
+tags: [data-modeling, relational, normalization, constraints, schema-design]
+official_sources:
+  - https://www.postgresql.org/docs/current/ddl.html
+verified: 2026-06-16
+---
+
+# Data Modeling
+
+## Overview
+Data modeling is the design of how data is structured, related, and constrained so it stays correct and queryable as the system grows. Relational modeling emphasizes normalization and referential integrity enforced by the database; document modeling embeds related data for read locality. Read this before creating a schema, adding a table, or choosing between relational and document storage.
+
+## Official sources
+- PostgreSQL — Data Definition (tables, constraints, keys, schemas, partitioning): https://www.postgresql.org/docs/current/ddl.html
+
+## Core concepts
+- **Tables, columns, and types**: a relational model defines entities as tables with typed columns; choosing correct types and defaults is the first integrity control.
+- **Constraints**: PostgreSQL supports NOT NULL, UNIQUE, CHECK, PRIMARY KEY, FOREIGN KEY, and EXCLUSION constraints — push invariants into the database so invalid data cannot be stored.
+- **Primary and foreign keys**: primary keys uniquely identify rows; foreign keys enforce referential integrity between related tables.
+- **Normalization**: organize data to eliminate redundancy and update anomalies (1NF/2NF/3NF) so each fact lives in exactly one place.
+- **Schemas and namespacing**: schemas group related objects and provide logical organization and access boundaries within a database.
+- **Document vs relational**: document models embed/denormalize related data for single-read access and flexible shape, trading integrity guarantees and join flexibility for read performance.
+
+## Best practices
+- Enforce invariants with database constraints (NOT NULL, UNIQUE, FOREIGN KEY, CHECK) rather than relying only on application code — the DB is the last line of defense.
+- Normalize to remove redundancy first; denormalize deliberately and only when measured read patterns justify it.
+- Always define primary keys and back foreign-key columns with indexes to keep referential checks and joins fast.
+- Choose data types tightly (e.g. proper numeric/timestamp types, generated/identity columns where appropriate) so the database validates and stores values efficiently.
+
+## Common pitfalls
+- Modeling everything as nullable text → loses validation and indexing benefits; use precise types and NOT NULL where the value is required.
+- Skipping foreign keys "for speed" → orphaned and inconsistent rows accumulate; let referential integrity be enforced by the engine.
+- Premature denormalization → duplicated facts drift out of sync; normalize first, denormalize only with evidence.
+
+## Examples
+```sql
+-- Relational schema with keys and constraints (PostgreSQL DDL)
+CREATE TABLE author (
+  id    bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
+  email text NOT NULL UNIQUE
+);
+
+CREATE TABLE post (
+  id        bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
+  author_id bigint NOT NULL REFERENCES author(id),
+  title     text   NOT NULL CHECK (length(title) > 0),
+  published boolean NOT NULL DEFAULT false
+);
+
+CREATE INDEX ON post (author_id);
+```
+
+## Further reading
+- PostgreSQL constraints reference: https://www.postgresql.org/docs/current/ddl-constraints.html
+- PostgreSQL table partitioning: https://www.postgresql.org/docs/current/ddl-partitioning.html
+
+## Related skills
+- ../system-design-fundamentals — partitioning and sharding at scale
+- ../caching-strategies — caching query results
+- ../api-design-rest-graphql — mapping the model to resources/types

package/skills/engineering/architecture/message-queues-async/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: message-queues-async
+description: Async messaging with queues and logs — delivery guarantees, ordering, and idempotency (Kafka, RabbitMQ); read before decoupling services.
+domain: engineering
+category: architecture
+tags: [messaging, queues, kafka, rabbitmq, idempotency]
+official_sources:
+  - https://kafka.apache.org/documentation/
+  - https://www.rabbitmq.com/tutorials
+verified: 2026-06-16
+---
+
+# Message Queues & Async Messaging
+
+## Overview
+Asynchronous messaging decouples producers from consumers in time and identity, smoothing load spikes and improving resilience. Apache Kafka is a partitioned, replayable log; RabbitMQ is a broker built around queues and exchanges. Both force you to reason about delivery guarantees, ordering, and idempotency. Read this before introducing a queue or event bus between services.
+
+## Official sources
+- Apache Kafka — Documentation (concepts, design, delivery semantics): https://kafka.apache.org/documentation/
+- RabbitMQ — Tutorials (queues, exchanges, work queues, pub/sub): https://www.rabbitmq.com/tutorials
+
+## Core concepts
+- **Kafka topics and partitions**: messages are published to topics split into partitions; ordering is guaranteed only within a single partition, and consumers track position via offsets.
+- **Kafka consumer groups**: a consumer group acts as one logical subscriber across multiple processes; any number of groups can consume the same topic without duplicating data.
+- **Delivery semantics**: systems offer at-most-once (may lose, never redelivers), at-least-once (never loses, may redeliver), or exactly-once. Kafka guarantees at-least-once by default.
+- **Kafka exactly-once**: from Kafka 0.11 the idempotent producer prevents retry-induced duplicates, and transactions with read-committed consumers enable exactly-once across read-process-write.
+- **RabbitMQ exchanges and routing**: producers publish to exchanges that route to queues by binding/routing keys, enabling work queues, publish/subscribe, routing, and topic patterns.
+- **Acknowledgements and confirms**: consumer acks and publisher confirms underpin reliable delivery — a message is only considered handled once acknowledged.
+
+## Best practices
+- Make consumers idempotent: because at-least-once delivery can redeliver messages, design handlers so processing the same message twice has no extra effect.
+- Use Kafka partition keys deliberately when you need per-key ordering, since ordering holds only within a partition.
+- Acknowledge after successful processing (manual acks / publisher confirms), not on receipt, so failures lead to redelivery rather than loss.
+- Reserve exactly-once for when you truly need it (Kafka transactions/idempotent producer); it adds overhead and is not always necessary if consumers are idempotent.
+
+## Common pitfalls
+- Assuming global ordering across a Kafka topic → ordering is per-partition only; key related messages to the same partition if order matters.
+- Acking a message before the work succeeds → message is lost on crash; ack only after the side effects are durable.
+- Ignoring duplicate delivery under at-least-once → double charges/sends; dedupe with idempotency keys or upserts.
+
+## Examples
+```text
+Idempotent consumer under at-least-once delivery:
+  on message m with key m.id:
+    if processed_ids.contains(m.id): ack(m); return   # dedupe
+    do_work(m)
+    processed_ids.add(m.id)
+    ack(m)                                             # ack after success
+```
+
+## Further reading
+- Kafka design — message delivery semantics: https://kafka.apache.org/documentation/#semantics
+- RabbitMQ publisher confirms tutorial: https://www.rabbitmq.com/tutorials/tutorial-seven-java
+
+## Related skills
+- ../software-architecture-patterns — event-driven architecture and queue patterns
+- ../scalability-reliability — queues for load leveling and resilience
+- ../system-design-fundamentals — throughput and partitioning trade-offs

package/skills/engineering/architecture/scalability-reliability/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: scalability-reliability
+description: Scaling, SLIs/SLOs, error budgets, and resilience tactics (timeouts, retries with backoff/jitter, load shedding); read before hardening a service.
+domain: engineering
+category: architecture
+tags: [scalability, reliability, slo, resilience, retries]
+official_sources:
+  - https://sre.google/books/
+  - https://aws.amazon.com/builders-library/
+verified: 2026-06-16
+---
+
+# Scalability & Reliability
+
+## Overview
+Scalability is the ability to handle growing load without proportional cost or latency blowups; reliability is delivering the intended function and recovering quickly from failure. Google's SRE practice frames reliability with SLIs, SLOs, and error budgets; the Amazon Builders' Library documents the concrete tactics — timeouts, retries with backoff and jitter, and load shedding. Read this before hardening a service or setting reliability targets.
+
+## Official sources
+- Google SRE books (SRE, the Workbook, Building Secure & Reliable Systems): https://sre.google/books/
+- Amazon Builders' Library (resilience and operations practices): https://aws.amazon.com/builders-library/
+
+## Core concepts
+- **SLI**: a Service Level Indicator is a quantitative measure of a service quality aspect — common examples are request latency, error rate, and availability.
+- **SLO**: a Service Level Objective is a target value or range for an SLI; it is the goal you operate against.
+- **SLA vs SLO**: an SLA adds explicit consequences (e.g. penalties) for missing targets; without consequences you are looking at an SLO, not an SLA.
+- **Error budget**: rather than demanding perfection, allow a rate at which the SLO may be missed and track it over time to inform release decisions.
+- **Timeouts, retries, backoff, jitter**: timeouts bound how long calls hang; retries mask transient faults; exponential backoff with jitter spreads retries to avoid synchronized spikes and congestion.
+- **Load shedding**: as a server approaches overload it should reject excess requests so it can keep latency low for the requests it does accept.
+
+## Best practices
+- Define a few meaningful SLOs from user-centric SLIs and manage to an error budget; keep aggregations simple and avoid unrealistic absolutes (per the SRE book).
+- Always set timeouts on remote calls so a slow dependency cannot tie up resources indefinitely.
+- Use exponential backoff with jitter for retries to avoid retry storms; consider adaptive retries with a token-bucket retry quota to cap amplification.
+- Be cautious with retries against an overloaded dependency — retrying a struggling system amplifies load; retry only when the dependency appears healthy, and shed load when overloaded.
+
+## Common pitfalls
+- Retrying without backoff/jitter → synchronized retry storms amplify an outage; add exponential backoff plus jitter.
+- Targeting 100% reliability → unsustainable and pointless past user perception; set an SLO with an error budget instead.
+- No timeouts on dependency calls → one slow dependency exhausts threads/connections and cascades the failure.
+
+## Examples
+```text
+Resilient remote call:
+  deadline = now + timeout
+  for attempt in 0..maxRetries:
+    try: return call(deadline)
+    except transient:
+      if dependencyUnhealthy(): break        # don't amplify overload
+      sleep( random(0, base * 2**attempt) )   # exponential backoff + jitter
+  raise Unavailable
+# Server side: if nearOverload(): reject(503)  # load shedding
+```
+
+## Further reading
+- SRE book — Service Level Objectives chapter: https://sre.google/sre-book/service-level-objectives/
+- Amazon Builders' Library — Timeouts, retries, and backoff with jitter: https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
+- Amazon Builders' Library — Using load shedding to avoid overload: https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/
+
+## Related skills
+- ../system-design-fundamentals — latency, throughput, and scaling trade-offs
+- ../message-queues-async — queues for load leveling and decoupling
+- ../caching-strategies — offloading origins to absorb load